-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In Unacceptable Behavior - Sustained Disruption of Discussion #261
Comments
This seems like good guidance. There is some overlap with Process section on Reopening a Decision When Presented With New Information. |
I don't think this is needed, because it is part of the W3C process. I would rather not repeat what is already in the W3C process. |
This is not part of the Process. The Process says "The Chair may reopen a decision when presented with new information", but does not give guidance to participants on continuing to raise issues without new information. It's not a repetition; I think it would be a good addition. |
I guess you're right that it's not stated explicitly in the process. But it certainly seems like an obvious implication. I like how it is written though. So to my mind it's a question of whether it is important and non-obvious enough to add to the length of the document, which I think is already a concern. Also, if the group chooses to include it, I suggest changing "contact the chairs" to "consult the W3C Process document", because contacting the chairs is not the appeal process that's described in the Process document. |
But this text is not talking about the appeal process, it’s the first step if you feel you have new information- which is to contact the chairs. If the chairs decide not to take it on and you dissent, then you would appeal the chairs’ decision. |
This is a good example of where the code and Process can work together as well. The Process has instructions for the chairs in this respect, and the code can reflect that (as it does in @jspellman's excellent wording). Putting this in the code would also give chairs/meeting facilitators some recourse in case this issue arises. This issue is inter-related with other parts of the code already, but I think having a code that reflects real things that might happen in our organization is only going to prove more useful for participants and chairs. |
I recommend adding an additional bullet (no label name, sorry).
The text was updated successfully, but these errors were encountered: