David,
thanks. I'll check with the PMC too.
Ian
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
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
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
|