fluo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject [DISCUSS] Path to committer-ship
Date Tue, 08 Oct 2019 20:40:25 GMT
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

Mime
View raw message