Governance document #45
Conversation
|
I suggest that in our definition of lazy consensus we include that there must be at least one vote in favor |
|
@bbriggs done |
|
|
||
| The project management committee has responsibilities beyond contributors that include participating in strategic planning, release planning, and approving changes to the governance model. They also have the duty of upholding the community code of conduct and ensuring its values. The PMC is also responsible for updating the community code of conduct. It also makes decisions when community consensus cannot be reached. | ||
|
|
||
| The PMC has final say over who can become a committer and will use lazy consensus for approval. Discussion over committer nominations will be done in private. |
There was a problem hiding this comment.
If transparency is a core value, why is this particular part done in private?
There was a problem hiding this comment.
I would also prefer if this is done publicly
There was a problem hiding this comment.
This was in the template... but I agree with it. In OpenStack we nominate and approve publicly, and what we've seen after years of doing that is no one is actually willing to downvote including someone publicly. On the infrastructure side we moved to doing it more privately, and I feel like the analysis of someones contributions to the project is more two-sided and honest.
I not against doing it publicly, but I think it will be overall harder on the community to do it that way. In general we try to praise people in public, and give criticism in private. Having a public mailing list where people discuss the good and the bad of your contributions to a project is going to be emotionally challenging. It's also difficult for the people reviewing your contributions to be honest in that situation. If a private conversation is had, then the response can be agreed upon. Either an announcement that a new committer has joined our ranks, or a private conversation between one or two committers and the candidate focused on where we'd like to see improvement.
There was a problem hiding this comment.
In https://theforeman.org/handbook.html:
Such objections may happen in public on the nomination thread. Understandably, however, not everyone is comfortable giving objections publicly. Therefore, it is acceptable for other committers to raise their concerns with the sponsor and/or other committers privately if they wish to do so. The sponsor is expected to update the nomination thread to show that it is on hold pending private concerns.
Regardless, during any objections, private or public, the nomination is on hold until the objections are resolved or the nomination is rejected. In the event of a failed nomination, the sponsor (as part of the discussing group) will know the grounds for the rejection, and can pass along constructive feedback to the candidate. Care should be taken to do this sensitively.
There was a problem hiding this comment.
The above linked document seems to indicate that the RFC is public by default with an option for private discussion. Despite the keen observation that, yes, human nature is to avoid going against the grain and disagreeing with a choice publicly, I feel that having a private-only vetting and approval process is ripe for abuse.
These are the people who will act as a steering committee for VP, resolve disputes, and provide overall guidance and direction. If they were put into their seat by a process that violates our core principle of transparency, what does that say about us?
I would like to provide the option for private objections to a nominee, but this overall process needs to be much more open.
There was a problem hiding this comment.
@bbriggs the PMC is elected publicly. We're just discussing giving out commit bit above.
There was a problem hiding this comment.
@nibalizer I think it is good to make the initial internal discussion private. So every member can bring the other up2date. the announcement + maybe furthers discussions should be public.
There was a problem hiding this comment.
"They also have the duty of upholding the community code of conduct and ensuring its values" is ambiguous. Is the PMC responsible for upholding the community CoC and ensuring the values of the CoC? Or is it responsible for upholding the community CoC and ensuring the values of the community? The sentence could say either.
Regardless, I looking in this repo for either a CoC or a statement of values and didn't find either. "I have to assume these are in another repo…?" she asked expectantly.
There was a problem hiding this comment.
we have the CoC here: https://voxpupuli.org/coc/
all repositories usually link to it.
There was a problem hiding this comment.
Yea we can link to that in here no problem. Though maybe the CoC moves in here and other things link in here.
|
On a first view this looks very good. I will take another look tomorrow. |
|
Can we do a quick It's a really great document though, kudos @nibalizer! |
|
|
||
| We do require one affirmative vote as part of the Lazy consensus model. | ||
|
|
||
| Organization-wide proposals can be proposed against the plubming repo(for governance, publishing, and miscellaneous issues), the modulesync repo(for standards and release/publishing issues), or the voxpupuli website repo(for communication and standards issues). As a courtesy, when you propose something you expect to be somewhat controversial, mention it in the voxpupuli chat room on freenode and get it added to the topic. |
There was a problem hiding this comment.
We need some spaces between letters and opening ('s.
|
The only thing I currently see missing is:
One other thing I would like to clear up is what the responsibilities of those 5 PMC members are. There's a few things noted but do specific PMC members have additional tasks that differ from the rest of the PMC's? Like one person is appointed to handle external comms on behalf of the project etc. or do we go full consensus/involvement by every PMC on everything? |
|
@daenney for elections, I tried to 'cheat' basically by saying everything would be up to the elections officer. By doing that we can punt the specific of elections down the road until our first election. That allows us to accept a governance document without getting stuck in the minutea of picking election procedures. Once we run an election, the election officer can run the election using common sense, and we can iterate on the process each year. We will almost certainly screw up writing a procedure (some case will be missed) so giving authority to someone to just do what makes sense, makes the most sense. |
|
@daenney for removal, I'll take a stab at that. @daenney for specific roles and responsibilities, I don't think we need to assign those in the governance documentation. Lazy consensus allows people to work on what they are interested in. If one person wants to take the lead on external communication, they can communicate that to the rest of the organization without needing it to be written down in the governance docs. Remember that the PMC can amend this document, so if roles do need to be set up, they can do that down the line. |
|
|
||
| Collaborators are community members who submit patches to the project. These patches may be a one-time occurrence or occur over time. Expectations are that contributors will submit patches that are small at first and will only grow larger once the contributor has built confidence in the quality of their patches. | ||
|
|
||
| *How to become one*: Submit a pull request to a VoxPupuli project |
There was a problem hiding this comment.
another common way for our project to become a contributor is to contribute a module/gem
or perhaps this comment is supposed to go below?
|
@nibalizer That sounds fair to me (w.r.t the roles). Thanks for clarifying! |
nibalizer
force-pushed
the
governance
branch
2 times, most recently
from
5f4b927
to
4eaf89e
Compare
| Users are community members who have a need for the project. They are the most important members of the community: without them, the project would have no purpose. Anyone can be a user; there are no specific requirements. Users should be encouraged to participate in the life of the project and the community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user activities include (but are not limited to): | ||
|
|
||
| * advocating for use of the project | ||
| * informing developers of project strengths and weaknesses from a new user’s perspective |
There was a problem hiding this comment.
Why qualify as "new"? It feels limiting when a simple "from a user's perspective" will do?
|
|
||
| *How to become one*: Submit a pull request to a Vox Pupuli project | ||
|
|
||
| Collaborators are community members who submit patches to the project. These patches may be a one-time occurrence or occur over time. It is anticipated that collaborators' contributions may be small at first, growing more considerable once the collaborator has built up the necessary knowledge, experience, and confidence. |
There was a problem hiding this comment.
These are sort of drive-by contributions. Is there another way to contribute outside of patches? We mention things like art, feedback, etc. in the Contributors section.
|
Notes from today's triage:
For the full notes, see https://github.com/voxpupuli/community-triage/blob/master/modules/notes/2016-08-11.md |
You're too late. We allow for at least 72hrs. You're of course welcome to raise a counterproposal/PR later to cancel it out. We need to set a threshold because otherwise we'll just deadlock and get into endless discussions where someone deems that someone else didn't wait long enough.
Module or tool actively causes damage or security issues, as far as I'm concerned
Sure, we can prevent many things. Hasn't been an issue before, premature optimisation.
Yes. If there are issues with a contributor you raise it with the PMC. This will most likely stem from CoC violations at which point the PMC is at liberty to investigate and take appropriate action
No, this is a governance document about how we steer the project in general. We can specify things around how we want PRs handled but not in here. That also will likely need much more revision as times change and freezing it in the governance document makes changing it much more involved.
I'm happy to do so since I won't be putting myself up for election.
Please no. It's unpleasant. We can do better.
Why? Suggestions are great but there needs to be some explanation as to why.
Didn't we just document lazy consensus over 72hrs? And again, PR workflow is not a governance thing. We also don't need to continuously reach all community members. The most active channel is IRC, Slack is pretty dead and so are the mailing lists and there's no requirement to get everyone's opinion all the time. Most people know who to poke for reviews for what modules. And seriously, over several weeks? What is this, MegaSlowPokeCorp Ltd Inc? Lets not over-regulate this, especially since we have no data to show that this is even remotely an issue right now. |
|
Thanks @hunner @bbriggs and @rnelson0 for your feedback on this. And thanks @daenney for answering so many of those questions. And a big thank you to @daenney for stepping up to be the first election officer. Did the wall of questions get answered sufficiently? I don't see anything in @daenney's answers that I could improve on. |
Template from http://outercurve.org/resources/governance/consensus_with_pmc.html From that: "This work is licensed under a Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License. This work is based upon "Meritocratic Governance Model" by University of Oxford. "
|
We discussed on IRC how we should move the document to a final stage. I didn't find any unclear spots left and would like to approve it from my side. Maybe we can start a little trend here and see how the rest thinks. |
|
Thanks @bastelfreak |
|
@voxpupuli/collaborators It's time! |
|
I apprrove. |
|
|
||
| *How to become one*: Be a collaborator and be nominated to the PMC as a contributor. Nominations should be sent to <email address for nominations>. You may nominate yourself. It is also common to give contributor status to an individual who donates code to the project by migrating a repository to the github namespace. | ||
|
|
||
| Contributors are collaborators who have shown wide dedication to the Vox Pupuli project in general or deep dedication to one project in particular, and the ability to work well with collaborators, users, and other contributors. The contributors have responsibilities beyond the collaborators. In particular, contributors formally decide on whether a pull request is merged or a release is cut. Contributors are recognized and valued for their contributions, in whatever form those contributions take. Tasks such as communication, documentation, art, packaging, and testing are all valued contributions. A contributor will use lazy consensus to decide on whether to merge a pull request from a collaborator. If the discussion is no longer moving towards a consensus, the PMC must vote via lazy consensus on whether the patch should be applied. |
There was a problem hiding this comment.
I'd prefer a link for lazy concensus down to that section as well
There was a problem hiding this comment.
I don't know how to do internal references like that in markdown... any hints?
There was a problem hiding this comment.
You need to create an anchor, like so:
## <a name="section"></a> Section
And then when you want to reference to it
Take me to [section](#section)
There was a problem hiding this comment.
Anchors are automatically created for headers in some markdown flavors, like GFM (Github Flavored Markdown). You can also create special ones, like @daenney mentioned.
One way to see what you already have is to click view on this doc and then try to click the links item that shows up to the left when you move the mouse over a heading. Or you can do what I did and construct it based on the words (lowercased) with a - where spaces are found in the header.
|
I approve. |
|
Following the rules of this document, I propose that we merge this document after 72 hours, starting now, if no one has blocking issues with that (as of Lazy Consensus, you do not have to explicitely agree). The remaining problems with this document can be addressed later; following the rules in this document. |
|
@roidelapluie sounds good. I padded it out to Sunday August 21st at 23:59 UTC. |
|
👍 I approve! Thanks for all the things @nibalizer ! |
|
I approve 👍 ʘ‿ʘ |
|
I approve 👍 |
|
@voxpupuli/collaborators Ping! We're not getting nearly the amount of responses I would expect for something that's going to form the foundation about how we grow and steer this thing. Please take a minute to read up. @voxpupuli/collaborators And one more thing... It would help us if you publicised your membership of VP on GitHub, it affects the numbers of collaborators we show on https://voxpupuli.org for example as we fetch them from the GitHub API and we don't get "private" members. Just go to https://github.com/orgs/voxpupuli/people/USERNAME and chose to publicise membership. There might of course be reasons that make you not want to do that which is perfectly fine, but all in all I think VP is one of the orgs I'm happy to show I'm a member of 😄. Thanks! |
|
lgtm! |
|
+1 |
|
I approve |
|
I won't have any possibilities to assist you based on the time frame you proposed. I'm only back the 9th of September and everything will need to have been decided and be in place before then, including how we're going to vote and any solutions around that. Do note that anyone that intends to run the elections cannot also nominate themselves for the elections. |
No description provided.