incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Louis Suárez-Potts <>
Subject Re: Incubator report sign-off
Date Fri, 19 Dec 2014 23:47:31 GMT

> On 19 Dec 2014, at 18:30, Benson Margulies <> wrote:
> On Fri, Dec 19, 2014 at 6:09 PM, Louis Suárez-Potts <> wrote:
>> Are we top posting now?
>> My comments below Ross’
>>> On 19 Dec 2014, at 16:33, Dennis E. Hamilton <>
>>> As a participant, I have two concerns about a player-mentor requirement.
>>> 1. Sustainability.  In many ways, it is mentors who need to have their attention
on The Apache Way and cultivating a sustainable project.  That means, from my perspective,
that mentors need to encourage others to do things, especially around project management and
procedural matters, and not just take on matters without leaving any bread crumbs.  It seems
important that others learn how to do that sort of thing too, whether or not special karma
is eventually required to perform the same activities.
>>> 2. I have learned repeatedly, and it is evidently well-known, that a developer
is his own worst project manager.  It has to do with attention being at a completely different
place when heads-down in development tasks than when heads-up watching the horizon and keeping
objectives and current effort aligned. When I am in developer mode, I need someone else to
pull my attention out of the weeds and look to see what course I am on and where I am at on
that course.
>>> I remember in the 60s when a colleague had ended up managing a project at GE
Medical Systems (or something similar) and he confessed that his team made a terrible mistake
-- they allowed him to program on their project.
>>> I'm not saying that a mentor could not be an effective player. I think doing
it well while mentoring is not common and it might interfere with training and development
as well.
>>> - Dennis
>>> -----Original Message-----
>>> From: Ross Gardler (MS OPEN TECH) []
>>> Sent: Friday, December 19, 2014 11:01
>>> To:
>>> Subject: RE: Incubator report sign-off
>>> Strawman:
>>> What if a mentor is *required* to be an active participant of the project. That
is contributing code, voting on releases and generally engaging with the community, they would
be a better mentor since they have a vested interest in the project itself. Sure, we might
reduce the number of projects coming into the foundation but (IMHO) that is not a problem.
Our goal as a foundation is not to be large, it is to be high quality.
>>> [ …
>>> ]
>> Accepting Dennis’ point, but I think that there’s a difference between being
in a large corporation doing in-house work and participating part time as a mentor. It’s
as if I were (as I do) to teach courses after work that relate to my expertise but are not
identical to it, if only because I like to think that I’m more advanced than any student
I’d have.
>> In prior instances where we’ve had mentors, or where I know of them, e.g., Mozilla’s
Firefox extension program at Seneca College, Toronto, where the lead instructor of the classroom
of students (as well as of individual pupils) is a developer at Mozilla. (He’s paid indirectly
by Mozilla to teach, I believe; that, at least, was at the arrangement we had with Seneca
for OpenOffice instruction, and ours was modelled on Mozilla’s.) In fact, the argument presented
to me by the instructor was that it was essential to be an active developer, at least if one
were instructing students on both the collaborative dynamics as well as the code itself. To
be sure, one need not be immersed in the project (i.e., have it as a day job), but being engaged
and current with the latest was important.
>> But to stipulate it as a requirement? Why? Why make it a requirement and not just
a recommendation, albeit a strong one? the only thing gained by making it a requirement—and
in bold, too—is to have a tool by which one could eliminate candidates. And I do not think
that is in the spirit of a pragmatic open source project.
>> louis
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> I'm not top-posting.
> I think the 'involved mentors' is part of an attempt to resolve
> several conflicting desires.
> The mentor model is that the PPMC members start out being all of the
> doers, and the mentors are coaches and supervisors.
> Conflict #1: coaching and supervising is not always a happy combination.
> Conflict #2: coaching means staying in the background to a large
> extend, as per Ross' statement. 'In the background' can be perilously
> close to 'gone fishing.' How does the IPMC (or whomever) tell the
> difference?
> Conflict #3: there's a shortage of people to mentor, and that leads to
> people with good intentions signing up and then failing to deliver.
> Over years, we've send many paragraphs of email trying to find a
> solution, navigating amongst these issues. We've added shepherds and
> emphasized champions. And, don't get me wrong, things are improved.
> 'Involved mentors' don't have conflict #1, because they are just part
> of the crew. They may be following the advice of a recent Bowen blog
> post and be planning for future un-involvement. That also cures
> problem #2. They aren't anxiously coaching from the sidelines. #3
> isn't going away, but this idea rate-limits new projects by the
> availability of serious bootstrappers.
> I agree that it's best to look at this idea as a candidate for an
> experiment rather than a moment in time to debate the existence of the

Can I suggest we look to instances where there has been open source mentoring? That is, some
methods work better than others, depending on the project and community, i.e., skills required,
skills acquired. 

Not all projects, not all architectures, not all communities are the same—that’s obvious.
Hence, my suggestion that we look at how others have done it (I suggest Seneca, but others
here have surely a lot of experience and instances to cite) and that we also proffer suggestions
and guidelines. 

BTW, I spend years dealing with this issue; that was in regards to OpenOffice, when it was
with Sun/Oracle. Several problems obtained. One was the basic reluctance of the company to
dedicate the needed resources that would make mentoring easier and less prohibitively expensive.

The other was that the architecture of the project itself introduced a Rubicon. What I promoted
as a way, if not around it, then as the start of a bridge, was to focus on extensions and
other modules whose building could lead to a more sophisticated developer, or at the least,
an engagement in the community.

@@ BTW, in looking over your enumeration, Benson, I was struck that implicit in it was a kind
of argument for a cooperative. That is, one could have as an obligation (is that the same
as requirement?) that committers dedicate N hours per unit of time to mentoring. I’ve not
seen this model in open source, but no doubt it’s been implemented in some place.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message