Room Meetings

February 2020

Starting message of the meeting

Agenda

Resolutions

Due to the unusual nature of this meeting, the lone subject was split into two sub-topics. Full transcript of both topics. Room Owners prepared a letter about the underlying issues to prepare the room for the discussion. The letter mostly restated the drama of the previous months and where ROs felt things were heading at the time.

The first part was about if SOCVR should participate in a proposed moderator strike. A starboard vote was taken and the results were 12-4-4 in favor of a strike if one were called.

The second part was about how we would implement the strike as a room. Per starboard vote the resolution was for freezing the room for the duration of the strike. Regular users would be invited into the Ministry of Silly Hats (off-topic chat).

April 2019

Starting message of the meeting

Agenda

  1. When should queues be allowed to avoid the "recent" rule?
  2. How should we deal with requests related to Meta discussions?
  3. Should (limited) re-posting of an expired *-pls request be allowed?
  4. Should SOCVR encourage cleanup of canonical questions?
  5. Should 'bad' or 'wrong' *-pls requests be binnable with some 3rd party user consensus?
  6. FAQ page rewrite

Resolutions

1. When should queues be allowed to avoid the "recent" rule? (GitHub issue) (Stars)

While there were concerns about possible abuse, the general consensus was that a Suggested Edit makes a question "active" for our purposes in SOCVR. CVQ entries do not.

2. How should we deal with requests related to Meta discussions? (GitHub issue) (Stars)

The general consensus was that topics on Meta should disallow any requests from being made, since we do not want the room dragged into Meta effect, especially without other users knowing about it. The rule applies only if you already know of a Meta involving the question.

3. Should (limited) re-posting of an expired *-pls request be allowed? (GitHub issue) (Stars)

There were several varying opinions raised on this. Some held that we should not allow reposts. Some held that it was impractical to police every request so let anyone repost at will. Still a third option was to allow one repost. After some discussion, consensus was around letting only one repost (generally relying on the honor system).

4. Should SOCVR encourage cleanup of canonical questions? (GitHub issue) (Stars)

While a general del-pls can always be posted, actual cleanups of canonical questions requires domain knowledge. Consensus was that full canonical cleanups are not something SOCVR will participate in.

5. Should 'bad' or 'wrong' *-pls requests be binnable with some 3rd party user consensus? (GitHub issue) (Stars)

While it was preferable that the OP be convinced to request a bin, consensus was that a bin could be forced if

6. FAQ page rewrite (GitHub issue) (Stars)

A suggestion had been made that the FAQ page rules are in a clunky list. Machavity had suggested a new format. There were some issues raised that could not be resolved within the short time of a meeting topic. As such, the decision was made to work through the issues within the GitHub system to rewrite the FAQ page

August 2018

Starting message of the meeting

Agenda

  1. SOCVR Sanitarium needs a better name
  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'?
  3. Should we wait until after the grace period is over before posting a cv-pls request?
  4. Should it be allowed to systematically target questions that are answered by a specific OP?
  5. Can we revisit a rule or FAQ about prescribed close reasons?

Resolutions

1. SOCVR Sanitarium needs a better name (GitHub issue)

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:

  1. Don't cv-pls a question you have an answer on.
  2. Don't cv-pls old stuff.
  3. Don't edit stuff to avoid Rule #2
  4. 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:

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 cv-pls request.

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 reopen-pls request.

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.

5. Can we revisit a rule or FAQ about prescribed close reasons? (GitHub issue)

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:

November 2017

Starting message of the meeting

Agenda

  1. 20k Deletion requests when not at deletion score threshold
  2. Is there any possibility that if we rant enough we can lower the cv's needed to close a question?
  3. Does SOCVR handle obviously terrible review audits?
  4. Tailor auto-comments
  5. Solidify Rules on Pinging Moderators?
  6. Should people be allowed to post approve-pls requests for their own tag-wiki suggested edits which remove plagiarism?

Resolutions

1. 20k Deletion requests when not at deletion score threshold

Add to the FAQ that when deletions should be considered, unless there's a good reason, it doesn't have to be now. Reasonable requests for quick deletion is more important than if it has -2 or -3.

2. Is there any possibility that if we rant enough we can lower the cv's needed to close a question?

Let put this in a separate room for some thoughts and suggestions , not something we want to push on now.

3. Does SOCVR handle obviously terrible review audits?

we don't need to do anything in the room. If a bad audit leads to a ban take it to meta. We could contribute a FAQ to meta.

4. Tailor auto-comments

Leave the user if they respond negatively or don't respond. If they respond positively, work with them at your own desire.

5. Solidify Rules on Pinging Moderators

Pinging mods engaged in general conversation is acceptable; Pinging mods for anything that could be handled with a flag is not acceptable; Ask the room about how to handle non-flag moderation problems. @ing a moderator for discussion is fine, you're just addressing them. @ing a moderator to fix your problem is not fine - that's what flags are for

6. Should people be allowed to post approve-pls requests for their own tag-wiki suggested edits which remove plagiarism?

the decision is to disallow it for now but remain open to the subject being revisited in the future when/if there is more info available from mods/employees. We ask Meta as well

May 2017

Starting message of the meeting

Agenda

  1. Suggested edits queue is full, Time to take a Stand?
  2. When are too many cv-pls, too many?
  3. Are proofread requests allowed?
  4. Remove link to user in cv-pls request
  5. Queen is breaking all our trains... How much can we take?
  6. Assign someone the job to update the content of SOCVR.org

Resolutions

1. Suggested edits queue is full, Time to take a Stand?

No need to intervene, let Stack Overflow solve their UX issues. No strong opposition to reviewing the queue in the room, as has been done in the past.

2. When are too many cv-pls, too many?

Keep the current guidelines of not posting walls of requests (max 4 or 5 in a row), remind regulars to review.

3. Are proofread requests allowed?

Those requests are tolerated, however it would be better to host such activities outside of SOCVR (GitHub Gist or another chatroom).

4. Remove link to user in cv-pls request

While no ones sees any issue in itself in removing the link, there has been concern expressed on how some policies (mainly the no-harassment one) can be difficult to follow, even by well-meaning regulars. This should further be discussed and clarified.

5. Queen is breaking all our trains... How much can we take?

We should ask bot authors to make sure their code doesn't flood the room with messages and requests, possibly implementing batching or self-deletion. For now, regulars and ROs don't find the bots too noisy as they rarely ever interrupt a conversation.

6. Assign someone the job to update the content of SOCVR.org

It's been decided that we should leverage GitHub issues and simply communicate about them in the room.

January 2017

Starting message of the meeting.

Agenda

  1. Do we need to watch our tone more?
  2. Do we still want to engage in burnination requests?
  3. We should have a way to disagree with vote requests, and move them to the graveyard if enough people agree
  4. Should we remove the room's events from the calendar?
  5. Can we fix Closey? Or implement an old, known working version?
  6. Should we allow del-pls requests on non-duplicate closed questions that would eventually be fetched by the Roomba?
  7. If you're gonna talk Politics (or any other off-topic stuff for that matter), you must respect those who disagree

Resolutions

1. Do we need to watch our tone more?

Stick to the prescribed CV reasons when making requests, and always use constructive language when describing a question. We already require members to act professionally and with a high standard.

2. Do we still want to engage in burnination requests?

No for anything longer than a week to finish. Meta has no invested support in burnination requests. "Help" from their end comes and goes like the wind. We wrote the FAQ entry for how burnination processes work, and we've been the only ones doing anything about it. We can take on ≤ 500 post burninations (that meet site requirements), anything more we'll have to talk about

Let's have fun with some burnination, smaller ones, where less frustration builds and instead we feel fulfillment.

3. We should have a way to disagree with vote requests, and move them to the graveyard if enough people agree

Yes, the functionality is wanted. Possible implementation: Have a formatted response like :<message ID> Disagree. <reasoning>. The graveyard script should also archive disagreements. Tracking through editing is not always a practical solution.

4. Should we remove the room's events from the calendar?

Our tooling and mindsets have evolved, the CV queue and the events hardly. Events can bind us as a room and be used as special moments to share moderation. We have to find a better way to handle them, a way to engage more people into them. Until then, have a pause and we'll disable the events.

5. Can we fix Closey? Or implement an old, known working version?

Yes, Sam is on it. Time for repairs: 6 to 8.

6. Should we allow del-pls requests on non-duplicate closed questions that would eventually be fetched by the Roomba?

There is nothing wrong with allowing them. It might be a "waste" for those people to use their votes on something that would be deleted anyways, but so far there has been no abuse from it. The question that matters is "should this be deleted right now?". These requests do not do any harm to the room.

7. If you're gonna talk Politics (or any other off-topic stuff for that matter), you must respect those who disagree

All discussions should be respectful and professional, regardless of topic. If discussion gets too far off-topic, it is everyone's responsibility to steer the direction back on-topic. Too much of any off-topic discussion is bad. Be Nice applies in the room, and any off-topic discussion that is too lengthy should be moved. if you want to do that disagree or debate thing, go into your own room.

The network as a whole has policies that control discussion (Be Nice). The room has a specific topic and it's necessary to have some extra policies, about that topic, but it also just needs to embrace network-wide policies, like Be Nice; there's no reason to add anything to them.

At the request of any RO, we should stop discussion of a given topic or move it elsewhere.

October 2016

Bookmark of the room meeting.

Agenda

  1. How do we handle motivated users with poor English skills?
  2. "Be Nice" topic
  3. Let's stop arguing daily about the appropriateness of close votes on specific questions
  4. Should room owners be moderating room members actions outside of the room?
  5. Room owner coverage

Resolutions

1. How do we handle motivated users with poor English skills?

The room is not an English learning site and there was no real issue with this in the past. Each user needs to decide if their English skill is good enough for them to properly operate on Stack Overflow (answering is part of that also). We can always point them at canned reason.

2. "Be Nice" topic

This was a single isolated incident that evolved into a big drama for really nothing. I think every party involved, including the RO team, understood what went wrong and learned from it. In the future, the ROs will try to be more responding to issues currently rising in chat, but it is important to add that everyone leads by example.

Just be nice. If you see something flagged and it could be inappropriate respect that someone felt that way and move on. We deal with people of all types from all over the world. There are going to be clashes and people are going to view things differently. Moving forward we just need to be more mindful of what we are saying and we need to not overreact if something gets flagged.

3. Let's stop arguing daily about the appropriateness of close votes on specific questions

This is pretty much already covered in the FAQ: "4. Avoid extended discussion about a cv-pls. We don’t have to agree about a close request. We’re not a democracy. However, users that are posting cv-pls’es that are blatantly wrong will be told so. The final verdict is on the RO team."

If you're having a back-and-forth between two well-defined 'teams', it's gone too long. You know when you hit that point. A blanket ban on discussion about cv-pls requests would defeat the purpose of the room and be unhealthy. Once you start repeating reasons for open or close you are just hitting a dead horse. No reason to keep going on.

4. Should room owners be moderating room members actions outside of the room?

The room owners are not moderators. If something needs moderating, get a moderator. If it's a room issue, handle it in the room.

Let alone we can't do that effectively, we don't even want to do that. People outside of the room can do as they want, as long as they follow SO rules and guidelines. Of course, when links to questions are left in the room, it is expected that they follow the room's rules. But we can't kick a user because we disagree with something they commented on Main or Meta.

5. Room owner coverage

If we need an RO in the room 24/7 then something is rotten in the room, and if we can't make this room work with all of us it is not going to work with just some RO's around.

August 2016

Bookmark of the room meeting.

Agenda

  1. Does the room/group need to be renamed to reflect the fact that it doesn't focus only on "Close" activity?
  2. Do we need more *-pls options directly in the CV-PLS userscript?
  3. What is the line for reporting 'all spam' or 'all bad suggested edits' for a particular user?
  4. There's a fine line between talking about / trying to promote the room and... well, spamming and pissing people off. How do we / should we advertise the room? Does it make a difference if it's main or Meta? Should we have any guidelines on the matter?
  5. Should SOCVR be involved in moderating the new Documentation portion of Stack Overflow?

Resolutions

1. Does the room/group need to be renamed to reflect the fact that it doesn't focus only on "Close" activity?

SOCVR is so ingrained that at this point it is impossible to change without confusion. Even though our reach has expanded close voting is still a major part of what we do. We are a brand and it is not a issue so we will not be changing the name.

2. Do we need more *-pls options directly in the CV-PLS userscript?

Yes, we want to do reject-pls for suggested edits as trial but we need to sit down and document the cases for such and then test. Candidates are: ties going the wrong way, obvious spam, rude, abusive and plagiarism.

3. What is the line for reporting 'all spam' or 'all bad suggested edits' for a particular user?

Unless posted by a moderator, we will not post any links to users. This means no !!/allspam and no reject-all. Our rule is no links to a user profile.

4. There's a fine line between talking about / trying to promote the room and... well, spamming and pissing people off. How do we / should we advertise the room? Does it make a difference if it's main or Meta? Should we have any guidelines on the matter?

Guideline: If it is relevant to the conversation at hand, fine. If it is out of the blue then just don't do it. That said, on Main, you don't say anything unless someone directly asks. On Meta, you can give some details if SOCVR could be relevant/useful in a discussion.

5. Should SOCVR be involved in moderating the new Documentation portion of Stack Overflow?

We will only moderate Docs for rude, abusive, spam and plagiarism. There won't be any moderation of low-quality, off-topic or otherwise incorrect examples.

April 2016

Agenda

  1. Can we ask for someone in the room to edit in a relevant tag on a question so that it can be single-handedly closed with the hammer?
  2. Should we leave a comment under posts that were closed as a result of a cv-pls in order to let the OP know how to improve their question? If so on which close reasons?
  3. Does the room/group need to be renamed to reflect the fact that it doesn't focus only on "Close" activity?
  4. Are the activities of the room effective at meeting its goals?
  5. What can / should we do to make our votes more effective?
  6. Are we okay with having a lot of members being privileged Smokey users? Should only RO be privileged in SOCVR and let members be privileged in Charcoal HQ if they really want to?
  7. Should we have an SOCVR Code of Conduct that all regulars are expected to follow, not only in SOCVR but also on SO / MSO / chat / any and all SE places?
  8. Creating editing events as well as close events (specially while burnating tags); if so, coordination of edits needs to be discussed.
  9. On smoke detector message where a post only needs to be edited, find a rule to avoid conflicting edits attempts. Example: we post a chat message "I will edit" or similar.
  10. Should we move the burnination process to a meta question?
  11. Should burnination be officially undertaken by SOCVR or should a new "Burninators" specialized room handle it?

Resolutions

1. Can we ask for someone in the room to edit in a relevant tag on a question so that it can be single-handedly closed with the hammer?

we will not allow tag-editing for handing off to gold badge holders.

2. Should we leave a comment under posts that were closed as a result of a cv-pls in order to let the OP know how to improve their question? If so on which close reasons?

No, we should not leave comments under posts that were cv-plsed. It is left up to the user making the request.

3. Does the room/group need to be renamed to reflect the fact that it doesn't focus only on "Close" activity?

Postponed to next meeting

4. Are the activities of the room effective at meeting its goals?

So yes I'd say we see on a daily basis that we are effective at meeting our goals

5. What can / should we do to make our votes more effective?

We need a diverse toolset, based on each others need, we need to evaluate what we have now, improve them in the next few months and re-visit this topic the next meeting.

6. Are we okay with having a lot of members being privileged Smokey users? Should only RO be privileged in SOCVR and let members be privileged in Charcoal HQ if they really want to?

we are fine with members of SOCVR having permissions to run the bot. RO's will monitor for bot misuse and anyone can bring up odd behavior to the Charcoal room.

7. Should we have an SOCVR Code of Conduct that all regulars are expected to follow, not only in SOCVR but also on SO / MSO / chat / any and all SE places?

If SO rules aren't good enough, let's fix the SO rules.

8. Creating editing events as well as close events (specially while burnating tags); if so, coordination of edits needs to be discussed.

Is there any disagreement to having trial edit events? spoiler: No

9. On smoke detector message where a post only needs to be edited, find a rule to avoid conflicting edits attempts. Example: we post a chat message "I will edit" or similar.

I think this should be the same as comments when cv-plsing. Not required or officially encouraged, but a "nice to do".

10. Should we move the burnination process to a meta question?

I made a start here: meta.stackoverflow.com/a/…

11. Should burnination be officially undertaken by SOCVR or should a new "Burninators" specialized room handle it?

I think burninations should not be chatroom dependent. If a chat room wants to donate it's resources, that's great. A meta answer should be the main hub for burnination coordination.

December 2015

The transcript is here

November 2015

The transcript is here