I have to -1 reductions in the code review quality bar as this leads to test problems, which leads to CI issues, which leads to gaps in coverage and then to delayed, bad and broken releases.
+1 on converting Google docs to either markdown or including them on the website since it is a valuable resource and becomes indexed via search engines. I don't have a strong opinion on the other topics discussed but many of them sound like good ideas. On Mon, Jan 29, 2018 at 7:21 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi, > > 1. The Apache Beam website contains a link to the Apache Code of Conduct > (on the > dropdown menu under the feather icon ;)). Maybe we can also add a link to > the > contribution guide as it's really important, especially for people who > target > the committership. > > 2. The retention time of Google doc is a valid point. Resume on the > mailing list > is a minimum. I like to have doc on the scm, but it means to use markdown > syntax > (it's what we are doing for some Apache projects). It's another option to > explore. > > 3. You got me point: it's subjective. The link to Flink doesn't bring > anything > more: "There is no strict protocol for becoming a committer". So, no > problem to > add such section, but I don't see lot of details providing there ;) > > Actually, Flink just copied the section from Apache: > > https://community.apache.org/contributors/ > > Maybe we can just refer this page. > > Regards > JB > > On 01/29/2018 03:30 PM, Ismaël Mejía wrote: > > Hello again, > > > > Some comments inlined: > > > > > > JB, > > > >> 1. The code of conduct is the one from Apache. > > > > Yes I am not necessarily saying that we need a new one, I am just > > saying that we need to make this explicit, not sure everybody is aware > > of it https://www.apache.org/foundation/policies/conduct.html > > > >> 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 agree that a resume to the mailing list is a must, but I was > > referring more to preservation purposes, google docs are really > > practical, but have the issue that can be removed without a ‘public’ > > copy in the open (at least the wiki will avoid this). This is still an > > open subject because we haven’t finished a proposal process (see > > below). > > > >> I don't see why and where Beam could be different from the other Apache > projects > > for the first three points. > > > > The three points are: > > 1. Code of conduct: I agree with you. > > 2. Proposal process: There is not Apache agreed way to do this, every > > community decides its way. And we haven’t finished this work, see > > https://issues.apache.org/jira/browse/BEAM-566 > > 3. Governance model: We follow the Apache process, but I agree that > > this is not the appropriate channel to discuss, since governance is a > > subject of the PMC. > > > >> I disagree about publishing the criteria to earn committership > > > > I understand because this can be subjective, I want to clarify that I > > am not in any case wanting to give a simple recipe to become committer > > because this simply does not exist, but if you take a look at the link > > I sent, you will see that we should make some points explicit, e.g. > > the importance of community building and the Apache Way. PTAL I think > > this is really good and I don't see why others could disagree: > > https://flink.apache.org/how-to-contribute.html#how-to- > become-a-committer > > > > > > Romain, > > > >> 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 agree with you, policy brings extra bureaucracy and this is > > something to avoid, but we need to make the areas where we are unaware > > of policies explicit and I think that we should link to such policies > > when appropriate as part of being an open community, e.g. reminding > > and respecting the code of conduct that we must follow is not a > > burden, it is a must. > > > > I will let the discussion still open and wait for others opinions, > > once the activity calms down I will wrap up and create new > > threads/JIRAs so we can track progress in the future. > > > > > > > > On Wed, Jan 24, 2018 at 2:19 AM, Robert Bradshaw <rober...@google.com> > wrote: > >> 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 > >>> > >>> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
