Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] To Mentors - how to handle new components from non-committers?

There's probably two approaches. Your PMC may have advise here too, on how other projects in Technology do similar things.

1) Just based on the one contribution (the initial one), a good description ("design document") of what the contribution does and how it fits in Paho, and a stated desire to continue long term to "be involved", you could vote to make the person a committer in Paho, with the understanding that your project, as a whole, uses "social convention" that "committers don't mess with others code" (meaning, they wouldn't change other components, without full review and approval of who was primarily in charge of the other components. [And, don't forget, things like "newsgroup posts", "blogs", "presentations", can also be used as a "history of contributions".] I suspect in this case their initial contribution should still go through the normal "large contribution" IP process at Eclipse, so they can scan the code for possible "copied from elsewhere" sort of violations. So, it is still "work" for existing committers, to "get in" that first contribution. But, every committer should strive to get new committers, groom them to become committers, give them encouragement, etc. It is "extra work", but necessary, and part of a every committers role.

2) Top level projects can have a "permanent incubation" project. I don't actually see such a repository for "Technology", but suspect they'd be fine setting that up, if you'd find it useful. (For example, the "webtools" project has "webtools/incubator/..." with a few repositories under that which serves this "incubation" purpose). This way, you could have "looser" rules for someone becoming a committer in the permeant incubator (though, social conventions still apply there too). These "incubating" components should (likely) use all normal "Paho naming conventions" so it'd be a simple matter to "move" them to the main repository if/when they became mature enough to join the main Paho code stream/repository.

The choice between the two probably depends on how many of these requests you get, their size, and their anticipated timeline/effort. "Lots and large and long" favoring option 2. But if its just a few, small ones, option 1 is probably easier overall. But option 1 probably does require more care in committers voting ... more frequently someone may have to say "I don't feel comfortable with this person or their contribution, as it just seems to be a short term experiment or example, and not a long term contribution". Whereas option 2 has the advantage you could accept an inexperienced person, and help groom them to gain experience, and later become a fully qualified committer with a good track record of helping the whole project.

In the end, "becoming a committer" is up to the other committers and I think as long as you have some documented rules, and treat everyone equally, either approach would be fine. To be honest, one of the reasons for the "track record" requirement is not so much to keep people from becoming committers, as it is prevent companies from having "role based" committership ... that is, it is unfair to other committers if some company decided, "oh, person X is going to a new job so we'd like person Y to take his place as a committer" (where, person Y is someone "out of the blue", without any history, track record, or relationships developed with the other committers).

Hope this helps (if not, ask again! :)
Good question, though, now that Paho itself is maturing enough to leave incubation!


From:        Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
To:        General development discussions for paho project <paho-dev@xxxxxxxxxxx>, David M Williams/Raleigh/IBM@IBMUS,
Date:        12/19/2013 07:22 AM
Subject:        To Mentors - how to handle new components from non-committers?

How should we best handle the development of new components from
non-committers?  I've been wondering about this for a while.  Having all
the new code come in via piecemeal contributions seems unwieldy during
the new development phase for a component.

One option of making the developer of a new component a committer seems
counter to the Eclipse approach to appointing committers via a good
track record of contributions.

On the other hand, waiting until a component is complete before
contribution seems counter to the open source spirit.

Perhaps Paho is atypical, being a collection of small, largely
independent components?

Ian Craggs

Back to the top