On Tue, Jan 23, 2018 at 9:29 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 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?
+1. I also agree with JB that we should be deferring to Apache for things like Code of Conduct, etc. (perhaps more explicitly, though that might not even be necessary). > 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). Agreed that using Github is a huge win here for lowering the bar for contribution. We still force people to go through JIRA to create and edit issues, and there's not much one can do there without an account (and even then it requires extra permissions to take an open issue) so maybe there's some improvement we could do there. I agree that the area with most room for improvement here is promptness in responding to PRs. This, together with our CI issues, I think our our primary pain points for the typical/new contributor. My best suggestion here is have someone (possibly part of a rotation) regularly triage issues, possibly pinging the author or reviewer. I'm -1 on lowering the bar of code that goes in; I think we can maintain a high bar in a welcoming atmosphere (and I find code review can be a good mentoring opportunity as well). High quality reviews take time, but are worth it in the long run. (On this note, there's an open question of whether non-committers can be reviewers.) Last point, I'm also strongly opposed to publishing criteria for becoming a committer; it's far to subjective of a judgement call and drawing lines here will hurt more than it will help (excluding worthy candidates and possibly creating a false sense of entitlement). There is already apache documentation on these roles at the appropriate level of generality. > 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 > >
