Re: Accepting new projects [was: LDAP taglib proposal]

[Pierre Delisle <pi...@sun.com>]

Hi Hen,

> > Here are some things we need to do to help us move forward:
> >
> > - All: Is this the right direction?
> 
> It slows things done a chunk, but as we're hardly a racing fast
> environment it seems more important to try and keep things moving with
> focus, which I think your suggestion will do.

Exactly. In a subsequent email, Mark seemed to also be in agreement:

  Mark wrote
  > ...
  > there should be a definite passage through your development process 
  > before files start showing up. We need to isolate that we all want to 
  > see the same results from the project. (ie right now some want a LDAP 
  > library while others want a JNDI library, while similar in architecture, 
  > they encompass different scopes of application).  Making sure that the 
  > design fits cleanly at both scopes is important.


> >   We still need to refine the proposal made above, but how
> >   does it sound in general? Is that the direction we should take to
> >   be more flexible in handling new project submissions?
> >   [the main difference with the current rules is that we would not
> >    mandate a project to be fully cooked before being accepted;
> >    we would simply require it to have clear motivation for its importance,
> >    clear commitment from the submitters, and clear interest from the
> > community).
> 
> Definitely +1. Allowing taglis to grow in the sandbox cannot be a bad
> thing. 

Great!

> This does mean often handing out Jakarta committerness to people
> for sandbox work, is this an issue with the PMC/Rules?

Will check with our local PMC representative (Craig McClanahan)...

> Maybe Jakarta need to define a 'sandbox-committer' type of person.

Yes, or a variation could be that we have taglibs-sandbox commit
privileges limited to our sandbox. Will see what Craig has to say
about it.

Thanks for commenting,

    -- Pierre

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Accepting new projects [was: LDAP taglib proposal]

[Pierre Delisle <pi...@sun.com>]

Thanks for the insight Craig.

More comments below...

> ...
> It is trivial (from a technical perspective) to allow commit privileges to
> the jakarta-taglibs-sandbox repository only, if that is appropriate.
> 
> As for process, you might look at the jakarta-commons project for an
> example charter that includes the concept of the Commons Sandbox:
> 
>   http://jakarta.apache.org/commons/charter.html
>
> What it boils down to is that the Commons Sandbox was designed to support
> experimentation and proposals, primarily from existing Jakarta committers
> (on any existing Jakarta project).  Therefore, the acceptance bar was set
> very low for such existing committers -- no permission at all is required
> to create a sandbox package, but a vote (by all commons-dev committers in
> that case) is needed to promote a package into Commons Proper.  [NOTE -
> you'll need to send a note to TAGLIBS-DEV to get appropriate karma on the
> jakarta-taglibs-sandbox repository, but I can turn that around quickly]
> 
> So what about non-Jakarta committers?  In practice, this hasn't come up
> very often, but informally Commons has set the bar progressively higher,
> in the two most common scenarios:
> 
> * One or more existing Jakarta committers want to start a
>   sandbox package, along with one or more non-Jakarta committers.
> 
> * One or more non-Jakarta committers want to start a sandbox package,
>   but no existing Jakarta committers are involved.
> 
> For Taglibs, the details of what you want to do are pretty much up to the
> community, but I'd suggest that the bar be pretty low in the first
> scenario (we want to encourage innovation and code sharing from existing
> Jakarta projects that might be generally useful) -- but the usual vote to
> accept a new committer would still be required.

We currently allow anyone who is a committer at
jakarta-tablibs to start a new project in the sandbox
(assuming a proper email for the new project submission is sent to the
list). It is therefore very easy in that case. Agree it should also be 
made easy for your first scenario.

> For the second scenario, I would recommend that the bar be somewhat higher
> -- basically along the lines of the standards for accepting a new package
> directly into Jakarta (existing codebase, existing developer community, at
> least advice from an existing Jakarta committer to teach the rules of the
> road, and so on).  Why?  Because Jakarta is not SourceForge -- we care as
> much (or even more) about the community and the development style as we do
> about the code.  Establishing a Jakarta sandbox project, simply for the
> purpose of *building* the development community, isn't really the right
> answer -- it's really better that the community exist already.  It's also
> much better, IMHO, that you have the active participation of at least one
> existing Jakarta committer on any sandbox project (which effectively turns
> the second scenario into the first one).
> 
> As I said, the details of how TAGLIBS-DEV wants to do this is pretty much
> up to your community (the PMC is more about making sure that code is
> licensed correctly, that committers are properly voted on, than they are
> about the details).  But my recommendations are included in the above
> paragraphs.

Keypoint here is that a project should not be created to build 
a community. Rather a community should already exist around the project
to ensure its success at jakarta.

Fair enough. Given Craig's achievements and many successes in the 
Open Source community, I think this is probably the best path to follow.

Other opinions?

In the meantime, do we have enough of a community around the JNDI/LDAP 
project to allow it to enter the sandbox? We've seen so far quite a few
people that voiced interest in working on that project. What seems to be missing
however is a committer willing to give it a +1...

Unless someone else wants to step up, I might be willing to cast that 
+1... but I'd like some of my questions to be clearly answered. 
More in my next email.

    -- Pierre

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Accepting new projects [was: LDAP taglib proposal]

["Craig R. McClanahan" <cr...@apache.org>]

See below for a few comments on process and procedure.

On Wed, 2 Oct 2002, Pierre Delisle wrote:

> Date: Wed, 02 Oct 2002 13:11:39 -0700
> From: Pierre Delisle <pi...@sun.com>
> Reply-To: Tag Libraries Developers List <ta...@jakarta.apache.org>
> To: Tag Libraries Developers List <ta...@jakarta.apache.org>
> Subject: Re: Accepting new projects [was: LDAP taglib proposal]
>
> Hi Hen,
>
> > > Here are some things we need to do to help us move forward:
> > >
> > > - All: Is this the right direction?
> >
> > It slows things done a chunk, but as we're hardly a racing fast
> > environment it seems more important to try and keep things moving with
> > focus, which I think your suggestion will do.
>
> Exactly. In a subsequent email, Mark seemed to also be in agreement:
>
>   Mark wrote
>   > ...
>   > there should be a definite passage through your development process
>   > before files start showing up. We need to isolate that we all want to
>   > see the same results from the project. (ie right now some want a LDAP
>   > library while others want a JNDI library, while similar in architecture,
>   > they encompass different scopes of application).  Making sure that the
>   > design fits cleanly at both scopes is important.
>
>
> > >   We still need to refine the proposal made above, but how
> > >   does it sound in general? Is that the direction we should take to
> > >   be more flexible in handling new project submissions?
> > >   [the main difference with the current rules is that we would not
> > >    mandate a project to be fully cooked before being accepted;
> > >    we would simply require it to have clear motivation for its importance,
> > >    clear commitment from the submitters, and clear interest from the
> > > community).
> >
> > Definitely +1. Allowing taglis to grow in the sandbox cannot be a bad
> > thing.
>
> Great!
>
> > This does mean often handing out Jakarta committerness to people
> > for sandbox work, is this an issue with the PMC/Rules?
>
> Will check with our local PMC representative (Craig McClanahan)...
>
> > Maybe Jakarta need to define a 'sandbox-committer' type of person.
>
> Yes, or a variation could be that we have taglibs-sandbox commit
> privileges limited to our sandbox. Will see what Craig has to say
> about it.
>
> Thanks for commenting,
>

It is trivial (from a technical perspective) to allow commit privileges to
the jakarta-taglibs-sandbox repository only, if that is appropriate.

As for process, you might look at the jakarta-commons project for an
example charter that includes the concept of the Commons Sandbox:

  http://jakarta.apache.org/commons/charter.html

What it boils down to is that the Commons Sandbox was designed to support
experimentation and proposals, primarily from existing Jakarta committers
(on any existing Jakarta project).  Therefore, the acceptance bar was set
very low for such existing committers -- no permission at all is required
to create a sandbox package, but a vote (by all commons-dev committers in
that case) is needed to promote a package into Commons Proper.  [NOTE -
you'll need to send a note to TAGLIBS-DEV to get appropriate karma on the
jakarta-taglibs-sandbox repository, but I can turn that around quickly]

So what about non-Jakarta committers?  In practice, this hasn't come up
very often, but informally Commons has set the bar progressively higher,
in the two most common scenarios:

* One or more existing Jakarta committers want to start a
  sandbox package, along with one or more non-Jakarta committers.

* One or more non-Jakarta committers want to start a sandbox package,
  but no existing Jakarta committers are involved.

For Taglibs, the details of what you want to do are pretty much up to the
community, but I'd suggest that the bar be pretty low in the first
scenario (we want to encourage innovation and code sharing from existing
Jakarta projects that might be generally useful) -- but the usual vote to
accept a new committer would still be required.

For the second scenario, I would recommend that the bar be somewhat higher
-- basically along the lines of the standards for accepting a new package
directly into Jakarta (existing codebase, existing developer community, at
least advice from an existing Jakarta committer to teach the rules of the
road, and so on).  Why?  Because Jakarta is not SourceForge -- we care as
much (or even more) about the community and the development style as we do
about the code.  Establishing a Jakarta sandbox project, simply for the
purpose of *building* the development community, isn't really the right
answer -- it's really better that the community exist already.  It's also
much better, IMHO, that you have the active participation of at least one
existing Jakarta committer on any sandbox project (which effectively turns
the second scenario into the first one).

As I said, the details of how TAGLIBS-DEV wants to do this is pretty much
up to your community (the PMC is more about making sure that code is
licensed correctly, that committers are properly voted on, than they are
about the details).  But my recommendations are included in the above
paragraphs.

>     -- Pierre
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>