On Wed, Jan 31, 2018 at 1:11 AM, Ismaël Mejía <ieme...@gmail.com> wrote:
> > For example if a > first-time contributor fixes some error and has the expected quality > we should accept it quickly, not being picky about some other part > that can be improved that was discovered during the review, I think that if it is really to quality we can merge. The problem I see is when it is not. I still think we want to stay positive and helpful and welcoming. We need a technical approach for how to actually help with code not just comments, which can sometimes seem nitpicky or adversarial. Two ways: 1. Propose a pull request to their fix branch. This is my favorite and I've mentioned it. Everything is straightforward and explicit. 2. Build a PR with their commits and your own. This is a bit more confusing and it does not help the contributor learn as well. Kenn > or at > least not doing this without some extra encouragement to do it as an > additional task. Also cases where the reviewer proposes an improvement > and then changes his mind must be absolutely avoided, or the reviewer > should at least ask for excuses or work on that part of the fix. These > ideas are to encourage contribution and not disappoint contributors, > and they apply to casual / initial contributors, with committers and > paid contributors these situations could be more acceptable even if > not ideal. > > On Tue, Jan 30, 2018 at 7:55 PM, Lukasz Cwik <lc...@google.com> wrote: > > 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 > > > > >
