From 5fabc3c89765ee0cfba5e00f4e7c51a417af78f4 Mon Sep 17 00:00:00 2001 From: Kevin Hunter Date: Sun, 18 Aug 2024 15:28:08 -0400 Subject: [PATCH] adding more pages --- room-info/celebrations.html | 58 ++++++++ room-info/history.html | 60 ++++++++ room-info/nominations.html | 111 +++++++++++++++ room-info/room-meetings/2015-11.html | 69 +++++++++ room-info/room-meetings/2015-12.html | 69 +++++++++ room-info/room-meetings/2016-04.html | 109 +++++++++++++++ room-info/room-meetings/2016-10.html | 91 ++++++++++++ room-info/room-meetings/2017-01.html | 97 +++++++++++++ room-info/room-meetings/2017-05.html | 91 ++++++++++++ room-info/room-meetings/2017-11.html | 92 ++++++++++++ room-info/room-meetings/2018-08.html | 137 ++++++++++++++++++ room-info/room-meetings/2019-04.html | 96 +++++++++++++ room-info/room-meetings/2020-02.html | 83 +++++++++++ room-info/room-meetings/info.html | 201 +++++++++++++++++++++++++++ 14 files changed, 1364 insertions(+) create mode 100644 room-info/celebrations.html create mode 100644 room-info/history.html create mode 100644 room-info/nominations.html create mode 100644 room-info/room-meetings/2015-11.html create mode 100644 room-info/room-meetings/2015-12.html create mode 100644 room-info/room-meetings/2016-04.html create mode 100644 room-info/room-meetings/2016-10.html create mode 100644 room-info/room-meetings/2017-01.html create mode 100644 room-info/room-meetings/2017-05.html create mode 100644 room-info/room-meetings/2017-11.html create mode 100644 room-info/room-meetings/2018-08.html create mode 100644 room-info/room-meetings/2019-04.html create mode 100644 room-info/room-meetings/2020-02.html create mode 100644 room-info/room-meetings/info.html diff --git a/room-info/celebrations.html b/room-info/celebrations.html new file mode 100644 index 0000000..e133ad0 --- /dev/null +++ b/room-info/celebrations.html @@ -0,0 +1,58 @@ + + + + + + + + + + + Celebrations - SOCVR + + + + + + + + + + + +
+

Celebrations

+

If you have reached a milestone you should celebrate it. So here we will list moderation milestones and milestones of the SOCVR chat room.

+ + +
+ + + + diff --git a/room-info/history.html b/room-info/history.html new file mode 100644 index 0000000..dc5ac64 --- /dev/null +++ b/room-info/history.html @@ -0,0 +1,60 @@ + + + + + + + + + + + History - SOCVR + + + + + + + + + + + +
+

History

+

Let's face it. The Close Vote Queue on Stack Overflow is huge. It's a dauntingly large number. At one point, it was over 100k. It's a much tamer amount now, but it can feel like your contributions don't amount to anything. Hence the start of the +initiative to start a Close Vote room back in 2013.

+

The room originated as a meeting place once a week to handle your 40 allotted review tasks. The feeling to make a dent with a couple of fellow users worked as an incentive. The motivation to make a difference is still there.

+

We feel your pain. We want to help. Together, we can make a dent.

+
+

Original FAQ on meta.SO (Mentioned here for attribution purposes)

+ +
+ + + + diff --git a/room-info/nominations.html b/room-info/nominations.html new file mode 100644 index 0000000..f3ec653 --- /dev/null +++ b/room-info/nominations.html @@ -0,0 +1,111 @@ + + + + + + + + + + + Nominations - SOCVR + + + + + + + + + + + +
+

Room Owner Nominations

+

Our chat room periodically looks for new Room Owners.

+

We use an "application/interview" style for new Room Owners. The workflow works like this:

+
    +
  1. The RO team announces the expansion of the RO team
    2. +
  2. Chat members write up a Github Gist of their nomination. This must be written by the person running for the position.
    3. +
  3. Anyone is free to write comments on the nominations to provide feedback and ask questions.
    4. +
  4. When nominations close (usually a week later) the RO team will evaluate the nominations and choose a winner.
    5. +
+

This page contains links to the different nominations to join the Room Owner team on SOCVR. Nominations are ordered by their nomination time, oldest first.

+

Humorous example nomination.

+

April 2019

+ +

August 2018

+ +

November 2017

+ +

October 2016

+ +

March 2016

+ +

January 2016

+ +

December 2015

+ + + +
+ + + + diff --git a/room-info/room-meetings/2015-11.html b/room-info/room-meetings/2015-11.html new file mode 100644 index 0000000..0444b92 --- /dev/null +++ b/room-info/room-meetings/2015-11.html @@ -0,0 +1,69 @@ + + + + + + + + + + + November 2015 - SOCVR + + + + + + + + + + + +
+

November 2015

+

The transcript is here

+ +
+ + + + diff --git a/room-info/room-meetings/2015-12.html b/room-info/room-meetings/2015-12.html new file mode 100644 index 0000000..ca9aca6 --- /dev/null +++ b/room-info/room-meetings/2015-12.html @@ -0,0 +1,69 @@ + + + + + + + + + + + December 2015 - SOCVR + + + + + + + + + + + +
+

December 2015

+

The transcript is here

+ +
+ + + + diff --git a/room-info/room-meetings/2016-04.html b/room-info/room-meetings/2016-04.html new file mode 100644 index 0000000..22f4877 --- /dev/null +++ b/room-info/room-meetings/2016-04.html @@ -0,0 +1,109 @@ + + + + + + + + + + + April 2016 - SOCVR + + + + + + + + + + + +
+

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. +
  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. +
  3. Does the room/group need to be renamed to reflect the fact that it doesn't focus only on "Close" activity?
    4. +
  4. Are the activities of the room effective at meeting its goals?
    5. +
  5. What can / should we do to make our votes more effective?
    6. +
  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. +
  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. +
  8. Creating editing events as well as close events (specially while burnating tags); if so, coordination of edits needs to be discussed.
    9. +
  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. +
  10. Should we move the burnination process to a meta question?
    11. +
  11. Should burnination be officially undertaken by SOCVR or should a new "Burninators" specialized room handle it?
    12. +
+

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.

+ +
+ + + + diff --git a/room-info/room-meetings/2016-10.html b/room-info/room-meetings/2016-10.html new file mode 100644 index 0000000..eba32ae --- /dev/null +++ b/room-info/room-meetings/2016-10.html @@ -0,0 +1,91 @@ + + + + + + + + + + + October 2016 - SOCVR + + + + + + + + + + + +
+

October 2016

+

Bookmark of the room meeting.

+

Agenda

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

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.

+ +
+ + + + diff --git a/room-info/room-meetings/2017-01.html b/room-info/room-meetings/2017-01.html new file mode 100644 index 0000000..4b8fe17 --- /dev/null +++ b/room-info/room-meetings/2017-01.html @@ -0,0 +1,97 @@ + + + + + + + + + + + January 2017 - SOCVR + + + + + + + + + + + +
+

January 2017

+

Starting message of the meeting.

+

Agenda

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

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.

+ +
+ + + + diff --git a/room-info/room-meetings/2017-05.html b/room-info/room-meetings/2017-05.html new file mode 100644 index 0000000..56b02d8 --- /dev/null +++ b/room-info/room-meetings/2017-05.html @@ -0,0 +1,91 @@ + + + + + + + + + + + May 2017 - SOCVR + + + + + + + + + + + +
+

May 2017

+

Starting message of the meeting

+

Agenda

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

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.

+ +
+ + + + diff --git a/room-info/room-meetings/2017-11.html b/room-info/room-meetings/2017-11.html new file mode 100644 index 0000000..cea339e --- /dev/null +++ b/room-info/room-meetings/2017-11.html @@ -0,0 +1,92 @@ + + + + + + + + + + + November 2017 - SOCVR + + + + + + + + + + + +
+

November 2017

+

Starting message of the meeting

+

Agenda

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

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

+ +
+ + + + diff --git a/room-info/room-meetings/2018-08.html b/room-info/room-meetings/2018-08.html new file mode 100644 index 0000000..30be6a0 --- /dev/null +++ b/room-info/room-meetings/2018-08.html @@ -0,0 +1,137 @@ + + + + + + + + + + + August 2018 - SOCVR + + + + + + + + + + + +
+

August 2018

+

Starting message of the meeting

+

Agenda

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

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. +
  2. Don't cv-pls old stuff.
    3. +
  3. Don't edit stuff to avoid Rule #2
    4. +
  4. Don't reopen-pls your own questions. You can still initiate discussions if they should be closed, though.
    5. +
+

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:

+ + +
+ + + + diff --git a/room-info/room-meetings/2019-04.html b/room-info/room-meetings/2019-04.html new file mode 100644 index 0000000..68d202e --- /dev/null +++ b/room-info/room-meetings/2019-04.html @@ -0,0 +1,96 @@ + + + + + + + + + + + April 2019 - SOCVR + + + + + + + + + + + +
+

April 2019

+

Starting message of the meeting

+

Agenda

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

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

+ +
+ + + + diff --git a/room-info/room-meetings/2020-02.html b/room-info/room-meetings/2020-02.html new file mode 100644 index 0000000..4364e86 --- /dev/null +++ b/room-info/room-meetings/2020-02.html @@ -0,0 +1,83 @@ + + + + + + + + + + + February 2020 - SOCVR + + + + + + + + + + + +
+

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).

+ +
+ + + + diff --git a/room-info/room-meetings/info.html b/room-info/room-meetings/info.html new file mode 100644 index 0000000..4d8f836 --- /dev/null +++ b/room-info/room-meetings/info.html @@ -0,0 +1,201 @@ + + + + + + + + + + + Info - SOCVR + + + + + + + + + + + +
+

Room Meetings

+

Periodically SOCVR has room-wide meetings where we discuss room policies and behavior.

+

Anyone can propose new topics to be discussed by creating an issue in the GitHub SOCVR Room Meeting Topics repository. The issues will be labeled with suggested-topic. Anyone interested is invited to comment and vote (GitHub emoji responses) on the topics. Doing so helps everyone prepare for the meeting, and allows people to share and discuss their views over a longer period of time than is available in the actual meeting.

+

When there are enough topics, the Room Owner (RO) team will announce a new date for a room meeting. The topics that will be on the agenda get labeled with the actual room meeting, like room-meeting-2017-01.

+

The meeting will be held in the room SOCVR Room Meetings. That room will be unlocked 30 minutes before the start of the meeting. You do not need to request access. Please don't request access, as doing so will just annoy all the ROs, all of whom are notified for each access request.

+

Meetings are scheduled to last one hour. That time is split between all topics, with a each topic given an equal maximum amount of time for discussion. If resolution is reached on a topic prior to the maximum time, then we will move on to the next topic.

+

During the meeting

+ +

After the meeting

+

After the meeting, the discussion on each topic is summarized, including any conclusions. The summary and conclusions are published on a page linked below, which is identified by the year and month in which the meeting took place.

+

Resolutions and transcripts from previous meetings:

+

2020

+ +

2019

+ +

2018

+ +

2017

+ +

2016

+ +

2015

+ + +
+ + + +