You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Ismaël Mejía <ie...@gmail.com> on 2018/01/23 16:43:33 UTC
[DISCUSS] State of the project: Culture and governance
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.
Re: [DISCUSS] State of the project: Culture and governance
Posted by Kenneth Knowles <kl...@google.com>.
Great starting points!
I agree w/ JB's point that some of this should be private@ discussion. I am
keeping my comments to things that I think everyone on dev@ should be part
of.
For all mentions of ASF policy: we should have our own link to the relevant
policy. It is hard enough for us to find ASF policy docs, and almost
impossible to know whether docs exist, whether you have the "right" ones or
"all" of them.
On Tue, Jan 23, 2018 at 8:43 AM, Ismaël Mejía <ie...@gmail.com> wrote:
>
> * Code of conduct
>
+1 to link to ASF policy
* Proposal process
>
+1 to link to ASF policy "it has to happen on list"
Design docs fall into the same category and coding and code review: use the
right tool. It would help to describe our practices and tools. I want to
see comments like: "let's move this from a PR to dev@" and "this needs a
design doc" and "these doc comments should move back to dev@" and also
"this is small enough you can just code it up".
> * Governance model
>
I think the biggest gaps we have are in governance of governance. ASF
policies establish about half of what is necessary, notably missing the
need for expiry and renewal. Mostly, we should be transparent about what
the PMC does and how often, etc. Threads on private@ of course are private
for a reason, but they should be private without seeming arbitrary or
mysterious.
* Contribution policies
- Avoid CI issues: Extremely long tests that break for unrelated
> issues should be minimized
>
+1 and this is in crisis IMO. Since "hope is not a strategy" I think we
need to cut scope and rebuild in a way where signals don't clobber each
other.
> - 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).
>
+0.5 I think we should reduce latency for response and document policy so
newcomers feel empowered to "ping".
-1 to any lower review standards. Discussion on a PR should build
community. You can also issue a PR to a PR and discuss *that* PR to show
even more outreach. There is no conflict between high quality code and
friendly community. Anyhow for me, I love to write, read, and discuss code
:-)
- We should add the previously discussed policy on stale PRs to the
> contribution guide.
>
+1
- Encourage a well balanced distribution of reviews, there are some
> committers that do many reviews, and of course this is not ideal.
>
+1 can we pull numbers or dashboard review load over time?
- Give priority for reviews / help to new contributors that are
> starting in the project or to critical fixes.
>
+1 especially new contributors
- ... commitership/PMC status...
> https://flink.apache.org/how-to-contribute.html#how-to-become-a-committer
+1 to link to ASF policy, maybe add something, maybe not.
Kenn
Re: [DISCUSS] State of the project: Culture and governance
Posted by Kenneth Knowles <kl...@google.com>.
On Tue, Jan 23, 2018 at 8:44 AM Ismaël Mejía <ie...@gmail.com> wrote:
> - Clear guidelines for the criteria to earn commitership/PMC status.
>
The PMC discussed this quite a bit and we have now added this to the web
site: https://beam.apache.org/contribute/become-a-committer/
Kenn
Re: [DISCUSS] State of the project: Culture and governance
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 4 févr. 2018 19:53, "Kenneth Knowles" <kl...@google.com> a écrit :
On Wed, Jan 31, 2018 at 1:11 AM, Ismaël Mejía <ie...@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.
On other apache projects i merged then fixed/enhanced a few times and it
works well while you dont rewrite the whole merged code. For people not
working on the project @work like me it is a good solution which avoids to
loose time on details and delay a merge a lot.
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é <jb...@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-becom
> e-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 <robertwb@google.com
> >
> >> > wrote:
> >> >> On Tue, Jan 23, 2018 at 9:29 AM, Romain Manni-Bucau
> >> >> <rm...@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é <jb...@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-becom
> e-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é
> >> >>>> jbonofre@apache.org
> >> >>>> http://blog.nanthrax.net
> >> >>>> Talend - http://www.talend.com
> >> >>>
> >> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >
> >
>
Re: [DISCUSS] State of the project: Culture and governance
Posted by Kenneth Knowles <kl...@google.com>.
On Wed, Jan 31, 2018 at 1:11 AM, Ismaël Mejía <ie...@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é <jb...@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 <robertwb@google.com
> >
> >> > wrote:
> >> >> On Tue, Jan 23, 2018 at 9:29 AM, Romain Manni-Bucau
> >> >> <rm...@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é <jb...@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é
> >> >>>> jbonofre@apache.org
> >> >>>> http://blog.nanthrax.net
> >> >>>> Talend - http://www.talend.com
> >> >>>
> >> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >
> >
>
Re: [DISCUSS] State of the project: Culture and governance
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@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 <ro...@google.com>
>>>> wrote:
>>>>> On Tue, Jan 23, 2018 at 9:29 AM, Romain Manni-Bucau
>>>>> <rm...@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é <jb...@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é
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
>>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [DISCUSS] State of the project: Culture and governance
Posted by Ismaël Mejía <ie...@gmail.com>.
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é <jb...@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 <ro...@google.com>
>> > wrote:
>> >> On Tue, Jan 23, 2018 at 9:29 AM, Romain Manni-Bucau
>> >> <rm...@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é <jb...@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é
>> >>>> jbonofre@apache.org
>> >>>> http://blog.nanthrax.net
>> >>>> Talend - http://www.talend.com
>> >>>
>> >>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
>
Re: [DISCUSS] State of the project: Culture and governance
Posted by Lukasz Cwik <lc...@google.com>.
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é <jb...@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 <ro...@google.com>
> wrote:
> >> On Tue, Jan 23, 2018 at 9:29 AM, Romain Manni-Bucau
> >> <rm...@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é <jb...@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é
> >>>> jbonofre@apache.org
> >>>> http://blog.nanthrax.net
> >>>> Talend - http://www.talend.com
> >>>
> >>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [DISCUSS] State of the project: Culture and governance
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <ro...@google.com> wrote:
>> On Tue, Jan 23, 2018 at 9:29 AM, Romain Manni-Bucau
>> <rm...@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é <jb...@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é
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>
>>>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [DISCUSS] State of the project: Culture and governance
Posted by Ismaël Mejía <ie...@gmail.com>.
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 <ro...@google.com> wrote:
> On Tue, Jan 23, 2018 at 9:29 AM, Romain Manni-Bucau
> <rm...@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é <jb...@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é
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
>>
Re: [DISCUSS] State of the project: Culture and governance
Posted by Robert Bradshaw <ro...@google.com>.
On Tue, Jan 23, 2018 at 9:29 AM, Romain Manni-Bucau
<rm...@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é <jb...@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é
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
>
Re: [DISCUSS] State of the project: Culture and governance
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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é <jb...@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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [DISCUSS] State of the project: Culture and governance
Posted by Jean-Baptiste Onofré <jb...@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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com