Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=DZpjhORs4myLPaVh5Owlgs4b1poQX1uZxGWONjSP4+juqC8y8KRypB5WODGVOn2rbl735xi9txg7MIUU3oo1CGA0Emmag0ur2ZMLbzMgvj0Ft9ASIJY1Qzu0AzmJP5v0YnE1HHwEucNQVAHgQKK5CyNPRKa/p0xJZcnd+bGe6Jk=
  ;
Message-ID: <20060706204708.51969.qmail@web60714.mail.yahoo.com>
Date: Thu, 6 Jul 2006 13:47:08 -0700 (PDT)
From: Ole Ersoy <ole_ersoy@yahoo.com>
Subject: Re: [discussion] Lowering barrier for perspective committers
To: Apache Directory Developers List <dev@directory.apache.org>
In-Reply-To: <20060706193553.83043.qmail@web60723.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Just a couple of more thoughts...

Have committer guidelines focused at the archetype
level.

So have some general global comitter guidelines that
go across all ADS projects (So one step below the
general apache guidelines), and then guidelines/rules
specific to each arcetype and that archetype's
instances.

The guidelines on the archetype should make it really
easy for someone to contribute and validate the
contribution on their own, thereby minimizing the
review effort of the archetype creator.
 
Encapsulate those guidelines in templates to the
extent possible and use code generation /
documentation generation as much as
possible...essentially just extend maven.


--- Ole Ersoy <ole_ersoy@yahoo.com> wrote:

> Hey Guys,
> 
> I try to do things in parallel as much as possible,
> so
> whenever I see something on ADS that has synergy
> with
> stuff I'm doing, I go ahead and add to both.  Thus
> when I'm learning about ADS, I take the time to post
> updates on the documentation as well.  I'm sure a
> lot
> of other people would do the same.  Like Alex said,
> this of coarse requires that they are aware of and
> how
> understanding of the various subprojects within ADS.
> 
> I'm going to propose some structural things here.
> 
> First Overall Project Principals
> - Simplicity, Visibility, Repeatability
> 
> Second Small project structures (Lego Blocks) made
> from maven archetypes.
> 
> Clearly stated knowledge requirements for each
> archetype.
> 
> So let me elaborate a little and make it more
> concrete.
> 
> I'll use the testing archetype I just started and
> put
> on JIRA as an example.
> 
> This is a type, like a java type except it creates a
> starting project structure for a specific type of
> project, for a project used in performance testing
> ADS.  Someone wanting to performance test ADS from
> scratch, would create an instance of this maven
> archetype, and use it to do the performance test.  
> 
> The important thing about it is that it gives
> developers a clear unambigous starting point for
> testing ADS.
> 
> Since it is created for a specific purpose its
> pretty
> easy to document it and explain how it works.
> 
> Also because of the way it's defined, it's easy to
> extend the work to other areas of testing and even
> other servers.
> 
> It minimizes any setup work for the developer in
> doing
> the performance test.
> 
> Since many instances of the archetype can be
> created,
> testing done with specific goals in mind can be
> isolated to an archetype instance, with a
> standardized
> way of documenting and interpreting results.
> 
> It makes the people making the archetype really put
> some thought into minimizing work for everyone else.
> 
> This in turn is easy to build on for everyone in the
> community, because everyone would start getting used
> to archetypes.
> 
> So for any project there would be a clearly defined
> starting point communicated through the structure of
> the archetype.
> 
> So by combining these structures and the general
> maven
> capabilities, most of the documentation for the
> project can be generated.  Then some high level
> directional stuff added on top for over the trees
> visibility.
> 
> I would also add use cases for each archetype, and
> the
> instances of the archetype, as well as how these fit
> in with the overall direction of the server.  Make
> this standardized in templates so that its generally
> understood that all the projects should follow this
> template standard.
> 
> Whenever I update the performance testing archetype,
> I'll add these ideas to the documentation so that
> what
> I'm saying becomes more concrete, and it will be a
> little easier to see the value in it.  If you check
> out the documentation for the project, you'll see
> that
> it's written in a breadcrumb like fashion, making it
> easy for anyone to see where I started and how I got
> the where it is now.  I always add to this before I
> do
> coding or anything.  This lets me see my thoughts in
> words, thus I'm doing a self check, before actually
> doing any implementation.  It facilitates my thought
> process and makes it
> 
> simple 
> 
> for others to follow in a 
> 
> repeatable
> 
> way.
> 
> Cheers,
> - Ole
> 
> 
> 
> 
> 
> 
> 
> 
> --- Alex Karasulu <aok123@bellsouth.net> wrote:
> 
> > John E. Conlon wrote:
> > > On Thu, 2006-07-06 at 09:43 -0400, Alex Karasulu
> > wrote:
> > > 
> > >> The number of active committers on Apache
> > Directory Server is dwindling 
> > >> and we have many areas where a single developer
> > has been working alone.
> > >> Some email threads have tried to address the
> > issue of the lack of enough
> > >> committers in specific areas: see threads [0] &
> > [1].  
> > > I seem to have had a ringside seat on these. 
> > Apologies if I contributed
> > > adversely to causing a break.
> > 
> > This whole OSGi effort was an undercurrent due to
> > the inexperience of 
> > some to engage the rest of the community.  Nothing
> > we cannot fix by just 
> > talking to each other though.  The key is not to
> > have isolated groups 
> > within a community that is already small.
> > 
> > >> So we are
> > >> suffering mostly in the following areas:
> > >>
> > >> o OSGi effort,
> > > Would help out all I can to move this forward.
> > Unfortunately the OSGi
> > > effort is an effort that requires a big picture
> > view of ADS internals
> > > and project direction. My ignorance of both has
> > impeded my efforts to
> > > help with much with the OSGi effort to date. 
> > 
> > No problem! No one person has the whole picture
> > crystal clear.  We can 
> > do this together.  It will take everyone to form
> > this picture.  This is 
> > why collaboration and communication are so
> important
> > especially with the 
> > OSGi initiative.
> > 
> > ...
> > 
> > >> As for new committers, I think we need to lower
> > the barrier for
> > >> committership while safely integrating these
> > committers into our
> > >> committer base.  One key need is to provide the
> > proper guidance while
> > >> reviewing their activity.  Up to now we've been
> > getting several
> > >> contributions and many are just collecting up
> in
> > JIRA.  
> > > Yes, although most of the OSGi related issues I
> > added were not commented
> > > on by active comitters, 
> > 
> > Without an introduction to what is going on, it is
> > very difficult for us 
> > to piece together the meaning of specific JIRA
> > issues.
> > 
> > I felt it best to just get them in to JIRA to
> > > notify anyone else attempting to work with ADS
> and
> > OSGi about what
> > > problems and issues they may encounter.
> > 
> > This was good to do however the email from
> Emmanuel
> > shows how people 
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com