- SOCVR Sanitarium needs a better name
- Do we need 'Do not request action on a post that you have asked or answered, or for an edit which you have made'?
- Should we wait until after the grace period is over before posting a cv-pls request?
- Should it be allowed to systematically target questions that are answered by a specific OP?
- Can we revisit a rule or FAQ about prescribed close reasons?
The name "SOCVR /dev/null" was chosen. The room name has been changed.
2. Do we need 'Do not request action on a post that you have asked or answered, or for an edit which you have made'? (GitHub issue)
There was considerable discussion. In fact, the topic of the discussion expanded to cover some other aspects of the request rules. Unfortunately, the conversation ended with what was thought by many to be a resolution, but was, at best, unclear as to its intent and scope. At worst, it would allow the possibility of considerable abuse.
The rule which was the one primarily under discussion was #15 in the FAQ (see above for the version as it was at that time). The intent of that rule is that users should not abuse SOCVR requests to gain an advantage for themselves (e.g. get more votes for their posts, prevent competing answers, etc.). In addition to not actually gaining advantage, there should not even be the appearance of gaining advantage from requests. We do not want SOCVR to be, or appear to be, a voting ring.
The discussion ended with the following specific items defined:
cv-plsa question you have an answer on.
- Don't edit stuff to avoid Rule #2
- Don't reopen-pls your own questions. You can still initiate discussions if they should be closed, though.
Other request types were not explicitly discussed.
Some people felt that what was decided was that the above items should completely replace FAQ #15. In addition, that it should replace much, if not all, of FAQ #11. Other people felt that these were supposed to be minimal modifications to FAQ #15, with no change to FAQ #11.
If the above items did replace FAQ #15, then it would, among other things, be permitted for users to
del-pls other people's answers on questions you've answered. That's, obviously, unacceptable, as it clearly violates the overall intent of not permitting requests where there's a conflict of interest. Another example is that it would permit
approve-pls requests on your own edits, which is something that had quite a bit of opposition when it was specifically discussed in a room meeting (see #6 of the November 2017 room meeting).
As to the replacement, or adjusting, of #11, it did not appear that most people really understood that was the effect of directly adopting the above items.
There have been multiple subsequent discussions on this topic, many of which have provided information on the diverging points of view as to what people felt the resolution of this topic was in the room meeting. The discussions which have taken place in SOCVR have included:
- Room meeting 2018-08: Additional to topic #2: 2018-08-25 01
- Room meeting 2018-08: Additional to topic #2: 2018-09-01 01
- Room meeting 2018-08: Additional to topic #2: 2018-09-03 01
- Room meeting 2018-08: Additional to topic #2: 2018-09-03 02
- Room meeting 2018-08: Additional to topic #2: 2018-09-04 01
- Room meeting 2018-08: Additional to topic #2: 2018-09-04 02
There were a few additional discussions regarding the Room Meeting in SOCVR, but they were primarily logistics (e.g. when will the summary be available).
Due to the problems inherent in the 4 items detailed above replacing either FAQ #15 in it's entirety, or with it replacing FAQ #15 and FAQ #11 (or just modifying them), we are not going to adopt them wholesale.
For now, we are making adjustments to FAQ #15 to loosen it, somewhat, in directions which it appears people desire, while still not permitting abuse or the appearance of SOCVR being a voting ring. For item #3 above, a new rule is being added to the FAQ, which is basically "don't manipulate the rules".
If the changes being made are not sufficient, or if there are unresolved problems, then this topic, or something much like it, can be covered again at the next room meeting. If there are ongoing issues, we would like them added to the Room Meeting Issues earlier rather than later, so that there can be discussion on the GitHub Issue well prior to whenever the next meeting is held.
As a point of order, the ROs have realized that we need to do a better job of keeping the discussion focused during the room meeting. We also need to encourage people to more actively participate in discussions on the GitHub issues prior to the meeting in order to better define what it is that is desired to be discussed and limit the topic to a scope that fits in the time we have available in a room meeting.
3. Should we wait until after the grace period is over before posting a cv-pls request? (GitHub issue)
There is no requirement to wait. Use your best judgment. If the question OP is responsive, and it looks like the question will be improved, then think about waiting to post a
Remember, the goal is good, on-topic questions.
Having a question be edited to be on-topic is something we want to have happen. When reviewing requests, if you see a question you feel has been edited into shape, mention it to (
@ ping) the person who requested it, so they can see if they want to withdraw their
cv-pls request (and closevote). If the now on-topic question is already closed, then please post a
4. Should it be allowed to systematically target questions that are answered by a specific OP? (GitHub issue)
User targeting is not permitted, including making requests about questions because a specific user posted answers to those questions. The FAQ is being updated to make it clear that this type of activity is an example of user targeting.
Concern by several people was expressed about seeing inappropriate request reasons. While various examples of inappropriate text were given by different people, it stood out that most of those included "Give me the Codez" (or similar) as a common thing they see which is inappropriate.
We will adopt the following guidelines for request reasons:
- Be Nice. The Stack Overflow Code of Conduct (CoC) applies to all chat messages, including requests.
- If you see a request, or any message, that isn't within the CoC:
- If within the 2 minute edit window, feel free to give the user who posted the request a friendly reminder, asking them to edit/delete; and/or:
- Anytime: ping an RO for removal, to handle repeat occurrences, etc.
- Beyond the CoC, requests should be business-like/professional.
cv-plsrequests: Including an actual close reason is highly recommended, even if that's your custom reason (e.g. "Custom: Homework without attempt"). Including an actual close reason significantly increases the likelihood that your request will be acted upon by other users.
del-plsrequests: Indicate why the post should be deleted, which is commonly also the reason it was closed. If the post can only be delete-voted by users with >20k reputation (e.g. any answer), then it's helpful to indicate that (commonly with a
20k+tag). It's also helpful to briefly indicate if the Roomba will, or will not, delete the question. The fact that the Roomba won't delete a question is a contributing factor to needing delete-votes. [Generally, unless it's urgent to delete a question, it's normal to allow the Roomba to delete the question rather than post a
del-plsfor it, if the Roomba will delete it in the relatively near future.]
- If, after evaluating the post reported to the room by a bot (e.g. FireAlarm or SmokeDetector), you are submitting a request about that post, or that post's question, then please indicate that by adding text similar to "(FireAlarm)" or "(SD report)" to the request reason.
- For all requests: Additional factual information in the request reason is fine, particularly when it's there to help other users save time in evaluating the post, or to help them make the choice to click-through to the question. Keep in mind that you're asking at least 4 other people to look at the question to evaluate it. If there's some short piece of information that reduces the amount of time others have to spend, or that indicates the request is easy to evaluate, including that information makes it much more likely for other people to handle your request.
- "No MCVE: no code"
- "Typo: see 5th line of 2nd code block:
bar. Confirmed by OP in comments."