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 <ctubb...@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
