Hi Ismael, More you add policies and rules around a project more you need energy to make it respected and enforced. At that stage you need to ask yourself if it does worth it?
I'm not sure it does for Beam and even if sometimes on PR you can find some comments "picky" (and guess me I thought it more than once ;)), it is not a bad community and people are quite nice. Using github is a big boost to help people to do PR without having to read a doc (this is key for contributions IMHO) so best is probably to manage to review faster if possible and be lighter in terms of review, even if it requires a core dev commit after a merge IMHO (while it doesnt break and bring something it is good to merge kind of rule). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> 2018-01-23 17:56 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi, > > I would like to remind: we are an Apache project, not an isolated one. > As an Apache member, it's really important to me. > > 1. The code of conduct is the one from Apache. > > 2. If it's not happen on the mailing list, it doesn't exist. That's the > Apache > rule. We already discussed about that in the past: having wiki or Google > doc is > not a problem as soon as a summary is sent on the mailing list. > > I don't see why and where Beam could be different from the other Apache > projects > for the first three points. > > A valid point is about contribution policies around CI and review. I > disagree > about publishing the criteria to earn committership, and even more for > PMC. As > already said, a contribution can have many forms, so, criteria in term of > number > can be inaccurate. > > As these subjects can be sensible, I would also prefer to discuss on the > private > mailing list first (to get agreement between the PMC members) before > publishing > publicly on the dev mailing list. > > My $0.01 > > Regards > JB > > On 01/23/2018 05:43 PM, Ismaël Mejía wrote: > > This is a sub-thread of the state of the project one initiated by > > Davor. Since this subject can be part of the community issues I would > > like to focus on the state of the project for its contributors so we > > don’t mix the discussion with the end-user thread. > > > > I hope other members of the community bring ideas or issues that we > > have/can improve to make contribution to this project easier and > > welcoming. I consider that this is a really important area, we need to > > guarantee that we have a sane culture for the project, where we > > respect contributors and anyone can feel safe to ask questions, > > propose ideas and contribute. We have done a good job until now but of > > course things can be still improved. > > > > Some ideas: > > > > * Code of conduct > > > > We don’t have a code of conduct, most communities deal with this only > > when problems arise. I think we should discuss this in advance, we can > > maybe write ours, or adopt one existing like the ASF one. It is > > essential that if we accept one code of conduct we really do take it > > into account, and respect it during all our community interactions, > > and apply actions in the cases when someone doesn’t. > > https://www.apache.org/foundation/policies/conduct.html > > > > * Proposal process > > > > So far we have a somehow loose but effective process with documents > > shared on google docs, and further discussion in the mailing list, we > > should formalize a bit more or finish the work on BEAM-566. Some > > guidelines on blockers for new proposals should be specified, e.g. > > backwards compatibility, etc. And most of this documents will better > > end as part of the website or some wiki for historical preservation. > > > > * Governance model > > > > Our governance model is of course based on Apache’s meritocracy one, > > we should encourage this, and always be aligned with the ASF policies, > > but also we need better criteria for consensus in technical decisions, > > so far the vote system has been a way to reach consensus but we have > > to find better ways to balance situations that can seem arbitrary or > > where technical decisions have to be made even with a lack of > > consensus, transparency and clear communication are key to avoid > > frustration. > > > > * Contribution policies > > > > So far we as a community have been welcoming on new contributions, but > > sometimes the contribution process seems harder than it should be. We > > need to make it as simple as possible: > > > > - Avoid CI issues: Extremely long tests that break for unrelated > > issues should be minimized > > - Review of pull requests should take less time than the current > > average (We should probably get some stats on this / define what is an > > acceptable review time and what is the expected process when a > > reviewer is not active). > > - We should add the previously discussed policy on stale PRs to the > > contribution guide. > > - Encourage a well balanced distribution of reviews, there are some > > committers that do many reviews, and of course this is not ideal. > > - Give priority for reviews / help to new contributors that are > > starting in the project or to critical fixes. > > - Clear guidelines for the criteria to earn commitership/PMC status. > > We should probably add these to the contribution guide or some other > > document. See Flink’s for example. > > https://flink.apache.org/how-to-contribute.html#how-to- > become-a-committer > > > > If you have some other ideas or issues that you would like to discuss > > please share them in this thread. > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
