[DISCUSS] Path to committer-ship

[Christopher <ct...@apache.org>]

Hi Fluo Devs,

A few of us met up in person at the Accumulo Hack Day (see Accumulo
dev list for details about that), and happened to discuss some
opinions on a typical path to committer-ship for contributors.

A few ideas that were discussed included:

1. Active on GitHub alone may be insufficient. Engagement on mailing
list is kind of required, because we need to have name and email
address to even invite somebody to be a committer on a project in the
Apache Software Foundation. So, it's a good idea to try to encourage
people to introduce themselves, especially if they are a regular
contributor.
2. Code contributions alone may be insufficient. It is important that
the community recognize the individuals as being "committed" to the
Fluo project in some way. So-called "drive-by" contributions are
higher risk, and the existing community may be reluctant to accept
them if there is an indication that the contributor may not stick
around to help maintain the code contributed. Even if the code is
accepted, there may be some reservations about inviting a contributor
whose commitment to the project is uncertain. This is fine if a
contributor is happy to be a contributor, but if they wish to be a
committer, they may need to demonstrate more active involvement than
providing code. They can demonstrate a commitment to maintain the code
they're contributing, or to help people use it effectively, or
document it better, or actively engage the community in other ways, in
addition to contributing code.
3. Contributing to a single sub-project inside Fluo, is totally fine.
People have different interests, and there's no reason we can't invite
somebody who is actively involved in one particular aspect, say
Muchos, even if they know little about the main Fluo project.
4. Consistently seeing specific names associated with contributions
makes it easier to identify who is doing the work for a PR, which
helps the existing PMC understand who to consider for inviting.
Sometimes, it can get confusing, if multiple people work on a PR, and
it's not clear who has earned the "merit" for the contribution.
5. Consistent engagement is key for inviting people to be committers.
It's easy for potential candidates to fall off the "radar" of the
existing PMC members, if they contribute, and then disappear. A
visible presence on the mailing list, in comments, in pull requests,
and bug reports, are important for existing PMC members to consider a
contributor for inviting them to be a committer.

Some other things I was thinking about that are ways people's
contributions can be noticed as merit-worthy and that I would consider
things on the path to be a committer:

1. Participate in code reviews
2. Vote (non-binding) on releases
3. Help with documentation
4. Providing feedback on proposed changes (on issue tracker or on mailing list)
5. Participate in discussions on the mailing list (and on the issue trackers)
6. Assisting users by answering questions
7. Helping triage issues

Does anybody else have suggestions or ideas on things one can do to go
from being a "contributor" to being a "committer"? Or thoughts on the
ideas that were discussed? Feel free to continue the discussion here.


--Christopher

Re: [DISCUSS] Path to committer-ship

[Christopher <ct...@apache.org>]

On Wed, Oct 9, 2019 at 11:35 AM Keith Turner <ke...@deenlo.com> wrote:
>
> My personal criteria is not well defined.  If someone shows up and
> makes good contributions in any form, then I would give them
> consideration.  One thing that is important to me is being civil
> during disagreements and attempting to reach consensus.
>
> On Tue, Oct 8, 2019 at 4:40 PM Christopher <ct...@apache.org> wrote:
> >
> > Hi Fluo Devs,
> >
> > A few of us met up in person at the Accumulo Hack Day (see Accumulo
> > dev list for details about that), and happened to discuss some
> > opinions on a typical path to committer-ship for contributors.
> >
> > A few ideas that were discussed included:
> >
> > 1. Active on GitHub alone may be insufficient. Engagement on mailing
> > list is kind of required, because we need to have name and email
>
> Personally I would not require any particular kind of mailing list
> interaction to consider someone.  We do need email addresses to invite
> though.

It's perhaps not strictly required, but it will be an expectation as a
PMC/committer. I said "kind of", mainly because it's a good way to get
a candidate's email. We could get it by other means (asking on GitHub
PR comments), but I think it's always good to encourage them to engage
the community, rather than us do the work, and definitely rather than
private conversations whenever possible. A good candidate is going to
need to get comfortable with using the mailing lists for project
business, as this is part of the Apache way. If they aren't willing to
share their email publicly, that's also going to put a damper on their
ability to accept an invite to be a committer and participate in
project business at ASF.

>
> > address to even invite somebody to be a committer on a project in the
> > Apache Software Foundation. So, it's a good idea to try to encourage
> > people to introduce themselves, especially if they are a regular
> > contributor.
> > 2. Code contributions alone may be insufficient. It is important that
> > the community recognize the individuals as being "committed" to the
> > Fluo project in some way. So-called "drive-by" contributions are
> > higher risk, and the existing community may be reluctant to accept
> > them if there is an indication that the contributor may not stick
> > around to help maintain the code contributed. Even if the code is
> > accepted, there may be some reservations about inviting a contributor
> > whose commitment to the project is uncertain. This is fine if a
>
> Personally I would only base decisions on past contributions and not
> try to infer the future.  Once an invitation is made, it can be
> declined if they feel its not right for them.

Recently, on another ASF list, I saw somebody trying to define what
"committer" meant in the context of non-code contributions, and
"commitment to the project" was suggested as a better description of
what a committer should be than "having commits in the project". So,
I've been trying to adopt that concept in the way I talk about
contributor activity.

So, I agree with you about basing decisions on past contributions.
What I was trying to summarize here wasn't that we should infer future
activity, but that we should look at more than "commits" and instead
infer "commitment" based on that past activity.

>
> > contributor is happy to be a contributor, but if they wish to be a
> > committer, they may need to demonstrate more active involvement than
> > providing code. They can demonstrate a commitment to maintain the code
> > they're contributing, or to help people use it effectively, or
> > document it better, or actively engage the community in other ways, in
> > addition to contributing code.
> > 3. Contributing to a single sub-project inside Fluo, is totally fine.
> > People have different interests, and there's no reason we can't invite
> > somebody who is actively involved in one particular aspect, say
> > Muchos, even if they know little about the main Fluo project.
> > 4. Consistently seeing specific names associated with contributions
> > makes it easier to identify who is doing the work for a PR, which
> > helps the existing PMC understand who to consider for inviting.
> > Sometimes, it can get confusing, if multiple people work on a PR, and
>
> I think multiple people working on a PR is great if they think that is
> the most efficient means to get something done.  For the purposes of
> tracking merit, using the git co-author mechanism is one possible way
> to do this.
>
> https://help.github.com/en/articles/creating-a-commit-with-multiple-authors

Agreed. I think one way that Fluo does already address this is that we
encourage all contributors to open a PR against the website to add
themselves. That can help us identify at least the initial
contribution from an individual. We may have to get smarter about how
we query the commit logs, though, if we're using that as evidence of
past contributions when considering candidates. If they are documented
in the commit logs, we may have to search outside the Author field
(such as looking at "Co-authored-by:" lines).

>
> > it's not clear who has earned the "merit" for the contribution.
> > 5. Consistent engagement is key for inviting people to be committers.
> > It's easy for potential candidates to fall off the "radar" of the
> > existing PMC members, if they contribute, and then disappear. A
> > visible presence on the mailing list, in comments, in pull requests,
> > and bug reports, are important for existing PMC members to consider a
> > contributor for inviting them to be a committer.
> >
> > Some other things I was thinking about that are ways people's
> > contributions can be noticed as merit-worthy and that I would consider
> > things on the path to be a committer:
> >
> > 1. Participate in code reviews
> > 2. Vote (non-binding) on releases
> > 3. Help with documentation
> > 4. Providing feedback on proposed changes (on issue tracker or on mailing list)
> > 5. Participate in discussions on the mailing list (and on the issue trackers)
> > 6. Assisting users by answering questions
> > 7. Helping triage issues
> >
> > Does anybody else have suggestions or ideas on things one can do to go
> > from being a "contributor" to being a "committer"? Or thoughts on the
> > ideas that were discussed? Feel free to continue the discussion here.
> >
> >
> > --Christopher

Re: [DISCUSS] Path to committer-ship

[Keith Turner <ke...@deenlo.com>]

My personal criteria is not well defined.  If someone shows up and
makes good contributions in any form, then I would give them
consideration.  One thing that is important to me is being civil
during disagreements and attempting to reach consensus.

On Tue, Oct 8, 2019 at 4:40 PM Christopher <ct...@apache.org> wrote:
>
> Hi Fluo Devs,
>
> A few of us met up in person at the Accumulo Hack Day (see Accumulo
> dev list for details about that), and happened to discuss some
> opinions on a typical path to committer-ship for contributors.
>
> A few ideas that were discussed included:
>
> 1. Active on GitHub alone may be insufficient. Engagement on mailing
> list is kind of required, because we need to have name and email

Personally I would not require any particular kind of mailing list
interaction to consider someone.  We do need email addresses to invite
though.

> address to even invite somebody to be a committer on a project in the
> Apache Software Foundation. So, it's a good idea to try to encourage
> people to introduce themselves, especially if they are a regular
> contributor.
> 2. Code contributions alone may be insufficient. It is important that
> the community recognize the individuals as being "committed" to the
> Fluo project in some way. So-called "drive-by" contributions are
> higher risk, and the existing community may be reluctant to accept
> them if there is an indication that the contributor may not stick
> around to help maintain the code contributed. Even if the code is
> accepted, there may be some reservations about inviting a contributor
> whose commitment to the project is uncertain. This is fine if a

Personally I would only base decisions on past contributions and not
try to infer the future.  Once an invitation is made, it can be
declined if they feel its not right for them.

> contributor is happy to be a contributor, but if they wish to be a
> committer, they may need to demonstrate more active involvement than
> providing code. They can demonstrate a commitment to maintain the code
> they're contributing, or to help people use it effectively, or
> document it better, or actively engage the community in other ways, in
> addition to contributing code.
> 3. Contributing to a single sub-project inside Fluo, is totally fine.
> People have different interests, and there's no reason we can't invite
> somebody who is actively involved in one particular aspect, say
> Muchos, even if they know little about the main Fluo project.
> 4. Consistently seeing specific names associated with contributions
> makes it easier to identify who is doing the work for a PR, which
> helps the existing PMC understand who to consider for inviting.
> Sometimes, it can get confusing, if multiple people work on a PR, and

I think multiple people working on a PR is great if they think that is
the most efficient means to get something done.  For the purposes of
tracking merit, using the git co-author mechanism is one possible way
to do this.

https://help.github.com/en/articles/creating-a-commit-with-multiple-authors

> it's not clear who has earned the "merit" for the contribution.
> 5. Consistent engagement is key for inviting people to be committers.
> It's easy for potential candidates to fall off the "radar" of the
> existing PMC members, if they contribute, and then disappear. A
> visible presence on the mailing list, in comments, in pull requests,
> and bug reports, are important for existing PMC members to consider a
> contributor for inviting them to be a committer.
>
> Some other things I was thinking about that are ways people's
> contributions can be noticed as merit-worthy and that I would consider
> things on the path to be a committer:
>
> 1. Participate in code reviews
> 2. Vote (non-binding) on releases
> 3. Help with documentation
> 4. Providing feedback on proposed changes (on issue tracker or on mailing list)
> 5. Participate in discussions on the mailing list (and on the issue trackers)
> 6. Assisting users by answering questions
> 7. Helping triage issues
>
> Does anybody else have suggestions or ideas on things one can do to go
> from being a "contributor" to being a "committer"? Or thoughts on the
> ideas that were discussed? Feel free to continue the discussion here.
>
>
> --Christopher