Sorry, but I fail to see the difference between Beam and other Apache project. It's not a github project: Beam follows the rules defined by the Apache Software Foundation.
Beam website/contribution guide or whatever should just point to Apache website resources. It's clearly explained and detailed. If you want to add additional details, no problem, but be sure I will double check that they are aligned and compliant with Apache rules. Regards JB On 01/31/2018 10:11 AM, Ismaël Mejía wrote: > Some extra comments inlined: > > JB, > >> 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. > > Sure we should put it the contribution guide, my idea is that we the > code of conduct more visible so everybody knows what to follow and > what to expect. > >> 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 ;) > > I disagree with the fact that doesn’t bring anything more, Beam can be > the first project a contributor approaches and in this case he/she > will not know this stuff, having some kind of guidance is important. > >> Actually, Flink just copied the section from Apache: >> https://community.apache.org/ > > From a quick look I could not find the same section there, but I agree > that we can add references to this Apache one if you can refer to me > the exact part where it is. > > > Lukasz, Kenn: > >> 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. > > Lowering the bar on code quality should be avoided. > > We still lack some clear rules for code reviews, this is probably > worth of an addition to the committer guide. 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, 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 >> >> -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
