thanks. I'll check with the PMC too.
On 19/12/13 17:39, David M Williams wrote:
There's probably two
approaches. Your PMC
may have advise here too, on how other projects in Technology do
1) Just based on the one
(the initial one), a good description ("design document") of
what the contribution does and how it fits in Paho, and a stated
to continue long term to "be involved", you could vote to make
the person a committer in Paho, with the understanding that your
as a whole, uses "social convention" that "committers don't
mess with others code" (meaning, they wouldn't change other
without full review and approval of who was primarily in charge
other components. [And, don't forget, things like "newsgroup
"blogs", "presentations", can also be used as a "history
of contributions".] I suspect in this case their initial
should still go through the normal "large contribution" IP
at Eclipse, so they can scan the code for possible "copied from
sort of violations. So, it is still "work" for existing
to "get in" that first contribution. But, every committer should
strive to get new committers, groom them to become committers,
encouragement, etc. It is "extra work", but necessary, and part
of a every committers role.
2) Top level projects can have a
incubation" project. I don't actually see such a repository for
but suspect they'd be fine setting that up, if you'd find it
example, the "webtools" project has "webtools/incubator/..."
with a few repositories under that which serves this
purpose). This way, you could have "looser" rules for someone
becoming a committer in the permeant incubator (though, social
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
The choice between the two
depends on how many of these requests you get, their size, and
timeline/effort. "Lots and large and long" favoring option 2.
But if its just a few, small ones, option 1 is probably easier
But option 1 probably does require more care in committers
voting ... more
frequently someone may have to say "I don't feel comfortable
this person or their contribution, as it just seems to be a
experiment or example, and not a long term contribution".
option 2 has the advantage you could accept an inexperienced
help groom them to gain experience, and later become a fully
committer with a good track record of helping the whole project.
In the end, "becoming a
is up to the other committers and I think as long as you have
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
companies from having "role based" committership ... that is,
it is unfair to other committers if some company decided, "oh,
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
track record, or relationships developed with the other
Hope this helps (if not, ask
Good question, though, now that
itself is maturing enough to leave incubation!
discussions for paho project <paho-dev@xxxxxxxxxxx>, David
12/19/2013 07:22 AM
To Mentors -
how to handle new components from non-committers?
How should we best handle the development of
non-committers? I've been wondering about this for a while.
the new code come in via piecemeal contributions seems
the new development phase for a component.
One option of making the developer of a new component a
counter to the Eclipse approach to appointing committers via a
track record of contributions.
On the other hand, waiting until a component is complete
contribution seems counter to the open source spirit.
Perhaps Paho is atypical, being a collection of small, largely
paho-dev mailing list