[ogb-discuss] Project creation guidelines (was: OGB Meeting Minutes :: 11/04/07)

[Eric Boutilier]

On Wed, 18 Apr 2007, Keith M Wesolowski wrote:
> On Wed, Apr 18, 2007 at 11:01:10AM -0500, Eric Boutilier wrote:
>
>> I see this was not addressed by `OGB/2007/001, Project creation
>> enhancements'. Presumably (correct me if I'm wrong) that is mainly due to
>> the resource limitation Stephen points out below and not because we want to
>> steer these types of people elsewhere.
>
> Nothing in my proposal precludes the creation of Project Teams
> consisting of a single individual.

Understood.

> It seems you're suggesting we create some sort of underclass...

Eek, no.

> of projects that aren't endorsed...

Yes, but perhaps not calling them Projects. (And definitely not calling
them anything uncomplimentary like underclass :-) )

> I considered this at length and rejected it for two reasons.  First,
> it's far too likely that a Project Team that hasn't been through the
> basic vetting process I proposed will reach a stopping point, seek to
> integrate, and then experience unpleasant surprises.

I don't think this applies because a not-officially-blessed coding effort
doesn't, at inception, seek to integrate. (If or when they do, then I would
think they'd need to seek normal community endorsement.)

> Examples might
> include having duplicated some other project that's approaching
> integration, having done work that's not what people actually want, or
> not meeting the requirements for integration.  These surprises lead to
> acrimony and bitterness. Second, the Constitution makes it quite
> clear that the way work gets done is that Community Groups sponsor
> projects.  We could, I suppose, have the OGB endorse otherwise
> unendorsed projects,

Or a provision for not-officially-endorsed status.

> but since endorsement is a decision with at least
> some technical (or at least domain-specific) basis, that would seem to
> fall afoul of the OGB's nontechnical purpose, not to mention
> effectively countermanding the decisions of more relevant Community
> Groups *not* to endorse the project.
>
> As I explicitly noted, the reason for the vetting...

Wait. It's not the existence of a vetting process that's at
issue, it's the idea of having an alternative, lower-bar,
vetting process, in trade for full rights (e.g. the right to
seek contributor status of voting eligibility).

> process is not fear
> of running out of resources but to ensure that the project is
> positioned for success.  It makes no difference whether the actual
> implementation will be done by 1 person or 100; what matters is that
> the team knows in advance what's needed, what's wanted, what else is
> going on, and who to go to with questions.  People who've done enough
> research themselves before proposing their projects will breeze right
> through, and the Community Group vetting process will be a no-op.
> People who don't will gain valuable knowledge along the way, and will
> find it easier the next time. Anyone who can't be bothered either to
> do the research or ask the Community Groups prior to starting work is
> not effectively a part of the OpenSolaris Community.

:-( I'm pretty sure I disagree strongly with that last
sentence, but see my next comment.

> , and is doing his
> or her work outside it.  That's fine; the licenses permit that, but
> we're here to support people who are a part of the Community, not
> those who consciously choose to operate outside it.

So I think one of the conclusions we can reach at this point is that your
views differ from mine with regard to where "inside", "outside", and "in
between" lie in this context.  Fair enough.

> Simply being
> hosted at a particular address doesn't make someone a part of the
> Community, and I see no reason to muddy the waters by implying that it
> does.  Why is it any more useful for a closed-development, unendorsed
> project to be hosted on opensolaris.org than for it to be hosted
> somewhere else?

I think mainly because there might be future coding efforts for which
opensolaris.org meets two key criteria: a.) It's the programmer's (or
programmers') first most optimal choice, and b.) it's the most optimal fit for
the kind of thing they want to work on.

> What would be useful are improvements that might make it more
> attractive for these people to join our Community instead of working
> in isolation.

I think this is another fundumental difference in our viewpoints; namely,
the potential value/nonvalue of work that comes from someone who chooses to
work in a much greater degree of isolation than the norm.

> Suggestions?

Other than my original one?
http://mail.opensolaris.org/pipermail/ogb-discuss/2007-April/000243.html