Re: [paho-dev] To Mentors - how to handle new components from non-commit

[David M Williams <david_williams@xxxxxxxxxx>]

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