Skip to content

PreBurp & Other Suggestions

Jump to bottom
robinCTS edited this page Mar 13, 2018 · 4 revisions

These suggestions/discussion points for the new pre-burp process are a combination of original ideas and the outcomes of the two meetings so far. There are also some suggested changes for the current burnination process.

Feel free to make any corrections/additions.

1) Summary of Possible New Request Categories/Subcategories (might need new mod-only? tags for some/most/all)

  1. Burnination
    1. Curate-Burn
      1. <1000? Qs for full/careful curating, requiring:
        1. Retagging
        2. Editing
        3. Migrating
        4. Culminates in mass deletion of remaining Qs (CM required?) and tag removal(/blacklisting)
    2. Bulk-Burn
      1. No Q limit? for bulk/mass tag removal/destruction
      2. Categorised using criteria based on (combination of):
        1. Vote count
        2. Views
        3. Other?
      3. Possibly merge with another tag if >90%? have both tags (mod required)
      4. Possibly after running a query to pick up minimal Qs to review
      5. Need to deal with spillage (untagged Qs, anything else?)
      6. Culminates in tag removal(/blacklisting) (CM required)
    3. Mini-Burn
      1. <50? Qs for mini-burn/one-user-burn
    4. Micro-Burn
      1. <5? Qs
      2. Any need to post a request? Or just do it
  2. Cleanup-Only
    1. Cleanup-Only
      1. ? Qs
      2. Only closing/migrating(/deleting) of Qs
      3. Tag not edited out (unless clearly inappropriate)
      4. Does not culminate in tag removal
      5. Can eventually lead to a burnination
  3. Disambiguation
    1. Disambiguation
      1. ? Qs
      2. Splitting a tag up into 2 (or more) tags if used for two completely different things
  4. Rename
    1. Rename
      1. Not sure if this should be separate or under Disambiguation
  5. Sweep
    1. Sweep
      1. Either too many Qs (will take too long)
      2. Or too ambiguous (too hard/will take too long)
      3. Or pointless (causes no harm)
  6. Declined
    1. status-declined
      1. Fails to meet the 4 required burnination criteria
      2. Other?

2) Existing-Tag (burnination-request) pre-burp Process (reusing the request Q)

  1. User posts a request using burnination-request
  2. Other users/OP add answers suggesting a category and a reason (maybe with a standard banner/tag at the top)
  3. Only one answer per category allowed
  4. Other answers are permitted as per the current burnination process (e.g. disputing the satisfaction of the 4 required criteria, etc). This means the "stupid" requests get triaged and never make it to the proposal stage
  5. Users vote on the question/answers
  6. If the following criteria are not satisfied,
    1. Any of the 4 requirements
    2. ?
  7. a mod does the following to "deny" the request:
    1. Adds the request to the "Master List" (see below)
    2. Adds status-declined
    3. Adds a canned declined-reason banner at the top
    4. Leaves the question open (allowing for the posting of a new answer to revisit the request)
  8. If the following voting criteria are satisfied and a category is determined,
    1. ?
  9. a mod does the following:
    1. Adds the request to the "Master List" (see below)
    2. Adds status-proposednew mod-only
    3. Adds the appropriate category and/or subcategory mod-tags
  10. The request then follows the existing burnination process (with any changes as required for the different subcategories)
  11. If the proposal is declined
    1. The preceding "deny" process is followed
    2. The "Master List" is updated
  12. If the proposal is completed
    1. The "Master List" is updated
  13. Is there a need to reserve the acceptance of an answer for a special reason? How to enforce it if so?
  14. An alternative to this process would be to spawn a new proposal Q

3) New-Tag (tagfix-request*) pre-burp Process (only spawning a new Q)

  1. User posts a request using tagfix-request* (or whatever the new tag is)
  2. The OP can post an answer suggesting which category should be used, or not if unsure
  3. Other users add answers suggesting categories and reasons (maybe with a standard canned banner/tag at the top)
  4. Only one answer per category allowed
  5. Other answers are permitted as per the current burnination process (e.g. disputing the satisfaction of the 4 required criteria, etc). This means the "stupid" requests get triaged and never make it to the proposal stage
  6. Users vote on the question/answers
  7. If the following criteria are not satisfied,
    1. Any of the 4 requirements
    2. ?
  8. a mod does the following to "deny" the request:
    1. Adds the request to the "Master List" (see below)
    2. Adds status-declined
    3. Adds a canned declined-reason banner at the top
    4. Leaves the question open (allowing for the posting of a new answer to revisit the request)
  9. If the following voting criteria are satisfied and a category is determined,
    1. ?
  10. a mod does the following to "propose" the request:
    1. Adds the request to the "Master List"
    2. Adds status-proposednew mod-only
    3. Spawns a new proposal Q, either as a copy or possibly a filled in template (may not be necessary for all subcategories)
    4. Adds the appropriate category and/or subcategory mod-tags to the proposal Q
    5. Adds a community wiki answer and/or a banner to the original request Q containing:
      1. A link to the "Master List"
      2. A link to the proposal Q
      3. A description of the appropriate process
      4. Other info?
  11. The new proposal Q follows the existing burnination process (with any changes as required for the different subcategories)
  12. If the proposal is declined
    1. The proposal Q is closed (can be reopened if the request is revisited)
    2. The preceding "deny" process is followed for the request Q
    3. The "Master List" is updated
  13. If the proposal is completed
    1. The proposal Q is closed
    2. status-completed is added to the request Q
    3. The "Master List" is updated
  14. Is there a need to reserve the acceptance of an answer for a special reason? How to enforce it if so?
  15. An alternative to this process would be to reuse the request Q

4) pre-burp Process Template?

  1. 4 criteria (fill out how the request satisfies them)
  2. Number of Qs
  3. Other info
  4. (Plus a template note explaining how to answer/vote)

5) Pros/Cons of the pre-burp Q Tag Alternatives

  1. Reusing burnination-request (+ reusing pre-burp Q by adding a subcategory tag)
    1. Pros:
      1. Users familiar with existing tag
    2. Cons:
      1. Users may be confused as the tag is the same but the process is different
      2. Might be confusing as there will be a mix of pre-burp and burnination answers/comments
      3. Requires a full set of new mod-only category tags
  2. Reusing burnination-request (+ spawning new Q)
    1. Pros:
      1. Users familiar with existing tag
    2. Cons:
      1. Users may be confused as the request jumps to another question.
      2. Possibly needs a new main tag for the spawned Q (burnination-categorised/burnination-proposal?)
      3. Requires a full set of new mod-only tags
  3. New tag, tagfix-request* (+ reusing pre-burp Q by removing the new tag and adding a category tag)
    1. Pros:
      1. New process, new tag
    2. Cons:
      1. Users need to be taught new process
      2. Existing answers and comments probably won't make sense
  4. New tag, tagfix-request* (+ spawning new Q with an appropriate tag)
    1. Pros:
      1. New process, new tag
      2. Spawned "Burnination" categorised requests can reuse the burnination-request tag and look exactly like the current requests
      3. pre-burp Q can be used for revisiting declined requests
    2. Cons:
      1. ?

6) * Suggestions for New Tag

  1. preburp-request
  2. preburn-request
  3. sanitation-request
  4. janitor-request
  5. incinerate-request
  6. carpet-request (sweeping it under the carpet)
  7. tagproblem-request
  8. tagfix-request
  9. fixtag-request
  10. sanitation-request

7) Miscellaneous pre-burp Process Questions/Ideas

  1. Only spawn Qs if they need featuring?
  2. What criteria to decide categorisation completed?
  3. Do we need to feature the pre-burp Q? (No)
  4. Post a new pre-burp Q to revisit declined requests?
  5. New category/subcategory tag format? category-? -request?
  6. If unsure what category a request should fall under:
    1. Make a judgement call
    2. Do a "triage" on a sample (see below)

8) Existing Burnination Process Changes

  1. status-declined

    1. Use to also close a request before reaching the featured stage.
    2. Should this happen automatically?
    3. What criteria should be used:
      1. Q<=0?
      2. How long after Q asked?
      3. What about recent activity?
      4. Sliding time scale?
    4. Alternatively, post an answer asking for post to be declined.
      1. Need to determine criteria for answer to be accepted/rejected.
      2. Will this affect searches for active requests?

  2. status-inprogressnew mod-only

    1. Use for in-progress burninations instead of status-planned

  3. status-planned

    1. Re-purpose for approved burninations

    So the request progress would proceed according to one of the following:

    • Proposal -> status-declined
    • Proposal -> status-planned -> featured -> status-declined
    • Proposal -> status-planned -> featured -> status-inprogressnew mod-only -> status-completed

  4. Reviewing a declined request

    1. Leave Q open and:
      1. Upvote Q
      2. Add an answer
      3. Add a comment
      4. Edit Q
      5. Flag the Q
      6. But who would see/action any of the above?
      7. Adding a comment to a "please decline" answer might work.
    2. Post a New Q, possibly with a new burnination-revisit/tagfix-revisit* tag
    3. Post a Master Question where renew requests are posted as answers or comments

  5. Is there a need to reserve the acceptance of an answer for a special reason? How to enforce it if so?

9) Master List of Requests

  1. https://meta.stackoverflow.com/questions/tagged/burninate-request+-status-completed+-status-declined
  2. Prioritize (how - by a mod? by SOCVR? by Trogdor? by voting on comments on the Master List Q)
  3. Current/future requests - is there a difference?
  4. Format?
    1. Spreadsheet (Google Sheets)
    2. GitHub Gist
    3. Meta post
  5. Separate lists or same list for different categories?

10) Possible pre-categorisation/processing/sieving/triaging of questions?

Useful for cleanups, curate-burns

  1. Format?
    1. Spreadsheet (Google Sheets)
    2. GitHub Gist
    3. Chat Rooms? (with a bot auto moving replied to posts to appropriate rooms)
    4. Custom Web App
  2. Process
    1. Each Q processed by precisely 1 (2? more?) users
    2. When triaging, user flags as ok, to be closed/edited/retagged, tag-inappropraite, unsure
    3. When burnination is in-progress allow "booking out" a selection of Qs (to avoid multiple users processing same ones)
    4. When booked out Qs are actioned, flag as
      1. In CVQ
      2. Kept (editted/retagged, etc)
      3. To be Migrated
  3. Features/Benefits
    1. Allows efficient loading up of the review queue, without overloading
    2. Can triage multiple requests in preparation for burninations, ie cue them up
    3. With a custom or Google Sheets or Chat Room solution, could auto track cvs
    4. Allows more efficient use of cvs:
      1. If you don't have enough cvs left to cover all the Qs, it is best NOT to vote on Qs @4cvs:
        1. If there is a excess of reviewers - makes no difference
        2. If there are not quite enough reviewers - allows the next reviewer with enough cvs to cover to use them all
        3. If there are precisely no other reviewers available for the next 4 days:
          1. Only in this worst case scenario is it better to nail the Qs @4cvs
          2. However, for this case (and whenever the queue is stalling) the better solution would be to bring it to the attention of SOCVR
    5. Allows loading up the queue with the same close-reason Qs for easier reviewing
  4. Problems
    1. Possible vandalism - might need to grant access on an individual basis

11) Pipelining Requests

Curate-burn +

  1. "Triaging"
  2. All other subcategories except Cleanup-Only
  3. Cleanup-Only needs special care not to flood the CVQ

12) Miscellaneous Miscellaneous

  1. Blacklisting tags
    1. Reserve closing of a pre_burp Q for blacklisted tags only?
  2. "DO NOT USE" on tags
    1. How to deal with it being ignored?
  3. Leveraging robo-reviewers
  4. SEDE query to return priority candidates
    1. http://data.stackexchange.com/meta.stackoverflow/query/493425/burninate-priority-list
    2. Max 100-200 Qs?
    3. Bad (low vote count) Qs?

13) Wish List - never happening (or maybe in 6 to 8 years)

  1. Make CVQ votes not count against daily cv total.
  2. Make CVQ votes on current burnination tag not count against daily cv total.
  3. Make cvs on current burnination tag not count against daily cv total!
  4. Double the number of CVQ reviews allowed on current burnination tag


    Image courtesy of Shog9
Clone this wiki locally