For
the record, that is not my recollection of the history at
all. Yes, that is perhaps an implicit side-effect. But the primary
motivations
that I recall at the time were (in order): (a) to help get projects off
to a
better start in understanding the processes and culture of the Eclipse
community
and (b) that it was a best practice observed from the Apache Foundation
that
had shown some success.
At
the time we were getting a lot of new projects at Eclipse and
many – if not most – appeared to floundering. Mentors were an
attempt to provide them with better support in their start-up phase.
I think that it would
be mistake to
say "if nobody in the larger Architecture Council wants to be a Mentor,
then we're going to require that the smaller Technology PMC take on
that
role". (a) The PMC already has a role to play in each project it
sponsors
and (b) the reason the community added the "need two Mentors from the
AC" was to constrain new projects to be only those things that the
broader community (as represented by the AC) is interested in.
You
know, I never understood the desire for having mentors in the
first place. Perhaps back when you could create a top-level project
from
scratch it made a certain amount of sense. At this point, I would argue
that it
is the job of the PMC of the project that accepts a project proposal to
mentor
the project. This is especially true for the Technology Project which
has
incubation as the primary goal.
Regarding
constraining projects, I
cannot even begin to comprehend why this would be a benefit to the
community.
The last thing we want to do is to turn Eclipse into a private club
where only
people who think in the same way are admitted. Just because no one on
the
Architecture Council is interested in a particular project proposal (or
has any
time left for mentoring) does not imply that the project proposal is
not
viable. As long as we are good about shutting down failed projects, I
do not
believe we should be putting in place artificial barriers to admission.
