Mailing-List: contact lucy-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@lucene.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Fri, 25 Jun 2010 03:11:54 -0000
Message-ID: <20100625031154.293.33168@eos.apache.org>
Subject: 
 =?utf-8?q?=5BLucy_Wiki=5D_Update_of_=22GraduationPlan=22_by_MarvinHumphre?=
 =?utf-8?q?y?=

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Lucy Wiki" for chan=
ge notification.

The "GraduationPlan" page has been changed by MarvinHumphrey.
The comment on this change is: Copied from http://incubator.apache.org/guid=
es/proposal.html.
http://wiki.apache.org/lucy/GraduationPlan

--------------------------------------------------

New page:
=3D=3D Abstract =3D=3D

A short descriptive summary of the project. A short paragraph, ideally one =
sentence in length.

The abstract should be suitable for reuse in the board resolution used to c=
reate the official project upon graduation, as the first paragraph on the p=
odling web site and in the DOAP document.
Examples: Geronimo will be a J2EE compliant container. Heraldry will develo=
p technologies around the emerging user-centric identity space. Yoko will b=
e a CORBA server.


=3D=3D Proposal =3D=3D

A lengthier description of the proposal. Should be reasonably declarative. =
More discursive material should be included in the rationale (or other late=
r sections).
Example (XAP): XAP is to provide an XML-based declarative framework for bui=
lding, deploying and maintaining rich, interactive, Ajax-powered web applic=
ations. A basic principal of XAP is to leverage existing Ajax ...

=3D=3D Background =3D=3D

Provides context for those unfamiliar with the problem space and history.

Explain terms whose meanings may be misunderstood (for example, where there=
 is not a single widely adopted definition).

This content should be capable of being safely ignored by domain experts. I=
t should probably find an eventual home on the Podling website.
Example (Heraldry): To provide some background, the Higgins Project is bein=
g actively developed within Eclipse and is a framework that will enable use=
rs and enterprises to integrate identity, profile, and relationship informa=
tion across multiple systems. Using context providers, existing and new sys=
tems such as directories, collaboration spaces ...

=3D=3D Rationale =3D=3D

Explains why this project needs to exist and why should it be adopted by Ap=
ache. This is the right place for discursive material.
Example (Beehive): There is a strong need for a cohesive, easy-to-use progr=
amming model for building J2EE applications. Developers new to Java are for=
ced to learn a myriad of APIs just to build simple applications; advanced J=
2EE developers are forced to write tedious plumbing code; and tools authors=
 are limited in what they can do to simplify the experience due to the unde=
rlying complexity.

=3D=3D Initial Goals =3D=3D

A complex proposal (involving multiple existing code bases, for example) ma=
y cause concerns about its practicality. A good way to address these concer=
ns is to create a plan that demonstrates the proposal is feasible and has b=
een carefully thought through.

Many projects will not need this section.
Example (Heraldry): * Expansion of Yadis and OpenID libraries into addition=
al languages beyond the existing Python, Ruby, Perl, and PHP libraries * Op=
enID authentication specification revision to fix known security considerat=
ions, investigate compatibility with the DIX IETF proposal, describe Yadis =
integration, and allow either an URL or XRI be used as the End User's Ident=
ifier ...

=3D=3D Current Status =3D=3D

This section (and the contained topics) describes the candidate's current s=
tatus and development practices. This should be an honest assessment balanc=
ing these against Apache's principles and development ideals.

For some proposals, this is a chance to demonstrate understanding of the is=
sues that will need to addressed before graduation. For others, this is a c=
hance to highlight the close match with Apache that already exists. Proposa=
ls without an initial code base should just simply state that.

Some proposals name this section criteria (though the term is a little misl=
eading).

=3D=3D=3D Meritocracy =3D=3D=3D

Apache is a meritocracy.

Once a developer has submitted enough good patches then it should be natura=
l that they are elected to committer. It should be natural that active comm=
itters are elected to the project management committee (PMC).

This process of renewal is vital to the long term health of Apache projects=
. This is the right place to demonstrate that this process is understood by=
 the proposers.
Example (OFBiz): OFBiz was originally created by David E. Jones and Andy Ze=
neski in May 2001. The project now has committers and users from around the=
 world. The newer committers of the project joined in subsequent years by i=
nitially submitting patches, then having commit privileges for some of the =
applications, and then privileges over a larger range of applications... Ex=
ample (Beehive): We plan to do everything possible to encourage an environm=
ent that supports a meritocracy. One of the lessons that the XMLBeans commi=
tters have learned is that meritocracies don't just evolve from good intent=
ions; they require actively asking the community for help, listing/specifyi=
ng the work that needs to be done, and keeping track of and encouraging mem=
bers of the community who make any contributions...

=3D=3D=3D Community =3D=3D=3D

Apache is interested only in communities.

Candidates should start with a community and have the potential to grow and=
 renew this community by attracting new users and developers. Explain how t=
he proposal fits this vision.
Example (Beehive): BEA has been building a community around predecessors to=
 this framework for the last two years. There is currently an active newsgr=
oup that should help us build a new community at Apache... Example (WebWork=
2): The WebWork 2 community has a strong following with active mailing list=
s and forums... Example (WADI): The need for a full service clustering and =
caching component in the open source is tremendous as its use can be applie=
d in many areas, thus providing the potential for an incredibly large commu=
nity...

=3D=3D=3D Core Developers =3D=3D=3D

Apache is composed of individuals.

It is useful to provide a brief introduction to the developers on the initi=
al committers list. This is best done here (and not in that section). This =
section may be used to discuss the diversity of the core development team.
Example (ServiceMix) The core developers are a diverse group of developers =
many of which are already very experienced open source developers. There is=
 at least one Apache Member together with a number of other existing Apache=
 Committers along with folks from various companies. http://servicemix.org/=
Team Example (WADI) WADI was founded by Jules Gosnell in 2004, it now has a=
 strong base of developers from Geronimo, Castor, OpenEJB, Mojo, Jetty, Act=
iveCluster, ActiveMQ, and ServiceMix.

=3D=3D=3D Alignment =3D=3D=3D

Describe why Apache is a good match for the proposal. An opportunity to hig=
hlight links with Apache projects and development philosophy.
Example (Beehive): The initial code base is targeted to run within Tomcat, =
but the goal is to allow the framework to run on any compliant Servlet or J=
2EE container. The Web services component, based on JSR-181, will leverage =
Axis. The NetUI component builds on top of Struts. The underlying Controls =
component framework uses Velocity. There are other projects that we will ne=
ed to work with, such as the Portals and Maven projects.

=3D=3D Known Risks =3D=3D

An exercise in self-knowledge. Risks don't mean that a project is unaccepta=
ble. If they are recognized and noted then they can be addressed during inc=
ubation.

=3D=3D=3D Orphaned products =3D=3D=3D

A public commitment to future development.

Recruiting a diverse development community and strong user base takes time.=
 Apache needs to be confident that the proposers are committed.
Example (Yoko): The contributors are leading vendors in this space. There i=
s no risk of any of the usual warning signs of orphaned or abandoned code.

Example (Ivy): Due to its small number of committers, there is a risk of be=
ing orphaned. The main knowledge of the codebase is still mainly owned by X=
avier Hanin. Even if Xavier has no plan to leave Ivy development, this is a=
 problem we are aware of and know that need to be worked on so that the pro=
ject become less dependent on an individual.

Example (Tika): There are a number of projects at various stages of maturit=
y that implement a subset of the proposed features in Tika. For many potent=
ial users the existing tools are already enough, which reduces the demand f=
or a more generic toolkit. This can also be seen in the slow progress of th=
is proposal over the past year. However, once the project gets started we c=
an quickly reach the feature level of existing tools based on seed code fro=
m sources mentioned below. After that we believe to be able to quickly grow=
 the developer and user communities based on the benefits of a generic tool=
kit over custom alternatives.

=3D=3D=3D Inexperience with Open Source =3D=3D=3D

If the proposal is based on an existing open source project with a history =
of open development, then highlight this here.

If the list of initial committers contains developers with strong open sour=
ce backgrounds then highlight this here.

Inexperience with open source is one reason why closed projects choose to a=
pply for incubation. Apache has developed over the years a store of experie=
nce in this area. Successfully opening up a closed project means an investm=
ent of energy by all involved. It requires a willingness to learn and to gi=
ve back to the community. If the proposal is based around a closed project =
and comes with very little understand of the open source space, then acknow=
ledge this and demonstrate a willingness to learn.
Example (Cayenne): Cayenne was started as an open source project in 2001 an=
d has remained so for 5 years.

Example (Beehive): Many of the committers have experience working on open s=
ource projects. Five of them have experience as committers on other Apache =
projects.

Example (Ivy): While distributed under an open source license, access to Iv=
y was initially limited with no public access to the issue tracking system =
or svn repository. While things have changed since then - the svn repositor=
y is publicly accessible, a JIRA instance has been setup since june 2005, m=
any new features are first discussed on the forum or JIRA - experience with=
 a true open source development model is currently limited. However, Maarte=
n has already a good experience with true open development process, and bri=
ng his experience to the project.

Example (River): The initial committers have varying degrees of experience =
with open source projects. All have been involved with source code that has=
 been released under an open source license, but there is limited experienc=
e developing code with an open source development process. We do not, howev=
er, expect any difficulty in executing under normal meritocracy rules.

=3D=3D=3D Homogenous Developers =3D=3D=3D

Healthy projects need a mix of developers. Open development requires a comm=
itment to encouraging a diverse mixture. This includes the art of working a=
s part of a geographically scattered group in a distributed environment.

Starting with a homogenous community does not prevent a project from enteri=
ng incubation. But for those projects, a commitment to creating a diverse m=
ix of developers is useful. Those projects who already have a mix should ta=
ke this chance to highlight that they do.
Example (Beehive): The current list of committers includes developers from =
several different companies plus many independent volunteers. The committer=
s are geographically distributed across the U.S., Europe, and Asia. They ar=
e experienced with working in a distributed environment.

Example (River) Since the Jini Technology Starter Kit has been mainly devel=
oped to date by Sun Microsystems, the vast majority of initial committers t=
o the project are from Sun. Over the years, Sun has received bug fixes and =
enhancements from other developers which have been incorporated into the co=
de. Our plan is to work with these other developers and add them as committ=
ers as we progress. There are three other initial committers (non Sun): Bil=
l Venners, Dan Creswell, and Mark Brouwer. Bill is the lead of the Service =
UI API work, Dan has been involved with much Jini-based development, includ=
ing an implementation of the JavaSpaces service called Blitz <http://www.da=
ncres.org/blitz/>, and Mark is veteran of much Jini-based development, incl=
uding commercial work at Virgil <http://www.virgil.nl> as well as leading t=
he open source Cheiron <http://www.cheiron.org> project.

Example (Ivy): With only two core developers, at least they are not homogen=
ous! Xavier and Maarten knew each other only due to their common interest i=
n Ivy.

=3D=3D=3D Reliance on Salaried Developers =3D=3D=3D

A project dominated by salaried developers who are interested in the code o=
nly whilst they are employed to do so risks its long term health.

Apache is about people, not corporations. We hope that developers continue =
to be involved with Apache no matter who their current employer happens to =
be.

This is a right place to indicate the initial balance between salaried deve=
lopers and volunteers. It's also good to talk about the level of commitment=
 of the developers.
Example (OpenJPA): Most of the developers are paid by their employer to con=
tribute to this project, but given the anticipation from the Java community=
 for the a JPA implementation and the committers' sense of ownership for th=
e code, the project would continue without issue if no salaried developers =
contributed to the project.

Example (River): It is expected that Jini development will occur on both sa=
laried time and on volunteer time, after hours. While there is reliance on =
salaried developers (currently from Sun, but it's expected that other compa=
ny's salaried developers will also be involved), the Jini Community is very=
 active and things should balance out fairly quickly. In the meantime, Sun =
will support the project in the future by dedicating 'work time' to Jini, s=
o that there is a smooth transition.

Example (Wicket): None of the developers rely on Wicket for consulting work=
, though two - Martijn and Eelco - are writing Wicket In Action (publisher =
Manning) in their spare time. Most of the developers use Wicket for their d=
ay jobs, some for multiple projects, and will do so for a considerable whil=
e as their companies (specifically Topicus, Cemron and Teachscape) choose W=
icket as their development framework of choice.

=3D=3D=3D Relationships with Other Apache Products =3D=3D=3D

Apache projects should be open to collaboration with other open source proj=
ects both within Apache and without. Candidates should be willing to reach =
outside their own little bubbles.

This is a an opportunity to talk about existing links. It is also the right=
 place to talk about potential future links and plans.

Apache allows different projects to have competing or overlapping goals. Ho=
wever, this should mean friendly competition between codebases and cordial =
cooperation between communities.

It is not always obvious whether a candidate is a direct competitor to an e=
xisting project, an indirect competitor (same problem space, different ecol=
ogical niche) or are just peers with some overlap. In the case of indirect =
competition, it is important that the abstract describes accurately the nic=
he. Direct competitors should expect to be asked to summarize architectural=
 differences and similarities to existing projects.
Example (OpenJPA): Open JPA will likely be used by Geronimo, requires some =
Apache products (regexp, commons collections, commons lang, commons pool), =
and supports Apache commons logging.

Example (River) Currently the only tie to Apache projects is the starter ki=
t's use of the Ant build tool. There are potential future ties (http server=
, database backend, etc)that will be explored.

=3D=3D=3D A Excessive Fascination with the Apache Brand =3D=3D=3D

Concerns have been raised in the past that some projects appear to have bee=
n proposed just to generate positive publicity for the proposers. This is t=
he right place to convince everyone that is not the case.

This is also the right place to build bridges with the community after past=
 misdemeanors (for example, if any of those associated with the proposal ha=
ve - in the past - sort to associate themselves with the Apache brand in fa=
ctually incorrect ways) and promise good conduct for the future.
Example (CeltiXfire): While we expect the Apache brand may help attract mor=
e contributors, our interests in starting this project is based on the fact=
ors mentioned in the Rationale section. However, we will be sensitive to in=
advertent abuse of the Apache brand and will work with the Incubator PMC an=
d the PRC to ensure the brand policies are respected.

Example (Wicket): The ASF has a strong brand, and that brand is in itself a=
ttractive. However, the developers of Wicket have been quite successful on =
their own and could continue on that path with no problems at all. We are i=
nterested in joining the ASF in order to increase our contacts and visibili=
ty in the open source world. Furthermore, we have been enthusiastic users o=
f Apache from the earliest hour (remember JServ anyone?), and feel honored =
at getting the opportunity to join the club.

Example (OpenJPA): We think that Open JPA is something that will benefit fr=
om wide collaboration, being able to build a community of developers and co=
mmitters that outlive the founders, and that will be embraced by other Apac=
he efforts, such as the Geronimo project.

=3D=3D Documentation =3D=3D

References to further reading material.
Examples (Heraldry): [1] Information on Yadis can be found at: http://yadis=
.org http://www.openidenabled.com [2] Information on OpenID can be found at=
: http://www.openid.net http://www.openidenabled.com The mailing list for b=
oth OpenID and Yadis is located at: http://lists.danga.com/mailman/listinfo=
/yadis ...

=3D=3D Initial Source =3D=3D

Describes the origin of the proposed code base. If the initial code arrives=
 from more than one source, this is the right place to outline the differen=
t histories.

If there is no initial source, note that here.
Example (Heraldry): OpenID has been in development since the summer of 2005=
. It currently has an active community (over 15 million enabled accounts) a=
nd libraries in a variety of languages. Additionally it is supported by Liv=
eJournal.com and is continuing to gain traction in the Open Source Communit=
y. Yadis has been in development since late 2005 and the specification has =
not changed since early 2006. Like OpenID, it has libraries in various lang=
uages and there is a large overlap between the two communities. The specifi=
cation is...

=3D=3D Source and Intellectual Property Submission Plan =3D=3D

Complex proposals (typically involving multiple code bases) may find it use=
ful to draw up an initial plan for the submission of the code here. Demonst=
rate that the proposal is practical.
Example (Heraldry): * The OpenID specification and content on openid.net fr=
om Brad Fitzpatrick of Six Apart, Ltd. and David Recordon of VeriSign, Inc.=
 * The domains openid.net and yadis.org from Brad Fitzpatrick of Six Apart,=
 Ltd. and Johannes Ernst of NetMesh, Inc. * OpenID libraries in Python, Rub=
y, Perl, PHP, and C# from JanRain, Inc. ... * Yadis conformance test suite =
from NetMesh and VeriSign, Inc. We will also be soliciting contributions of=
 further plugins and patches to various pieces of Open Source software.

=3D=3D External Dependencies =3D=3D

External dependencies for the initial source is important. Only some extern=
al dependencies are allowed by Apache policy. These restrictions are (to so=
me extent) initially relaxed for projects under incubation.

If the initial source has dependencies which would prevent graduation then =
this is the right place to indicate how these issues will be resolved.
Example (CeltiXfire): The dependencies all have Apache compatible licenses.=
 These include BSD, CDDL, CPL, MPL and MIT licensed dependencies.

=3D=3D Cryptography =3D=3D

If the proposal involves cryptographic code either directly or indirectly, =
Apache needs to know so that the relevant paperwork can be obtained.

=3D=3D Required Resources =3D=3D

Resources that infrastructure will be asked to supply for this project.

=3D=3D=3D Mailing lists =3D=3D=3D

The minimum required lists are project-private (for confidential PPMC discu=
ssions) and project-dev lists. Note that projects historically misnamed the=
 private list pmc. To avoid confusion over appropriate usage it was resolve=
d that all such lists be renamed.

If this project is new to open source, then starting with these minimum lis=
ts is the best approach. The initial focus needs to be on recruiting new de=
velopers. Early adopters are potential developers. As momentum is gained, t=
he community may decide to create commit and user lists as they become nece=
ssary.

Existing open source projects moving to Apache will probably want to adopt =
the same mailing list set up here as they have already. However, there is n=
o necessity that all mailing lists be created during bootstrapping. New mai=
ling lists can be added by a VOTE on the Podling list.

It is conventional to use an all lower case, dash-separated (-) prefix base=
d on the project name.

By default, commits for {podling} will be emailed to {podling}-commits. It =
is therefore recommended that this naming convention is adopted.
Example (Beehive): * beehive-private (with moderated subscriptions) * beehi=
ve-dev * beehive-commits * beehive-user

=3D=3D=3D Subversion Directory =3D=3D=3D

It is conventional to use all lower case, dash-separated (-) directory name=
s. The directory should be within the incubator directory space (http://svn=
.apache.org/repos/asf/incubator).
Example (OpenJPA): https://svn.apache.org/repos/asf/incubator/openjpa

=3D=3D=3D Issue Tracking =3D=3D=3D

Apache runs JIRA and Bugzilla. Choose one. Indicate the name by which proje=
ct should be known in the issue tracking system.
Example (OpenJPA): JIRA Open-JPA (OPEN-JPA)

=3D=3D=3D Other Resources =3D=3D=3D

Describe here any other special infrastructure requirements necessary for t=
he proposal. Note that the infrastructure team usually requires a compellin=
g argument before new services are allowed on core hardware. Most proposals=
 should not require this section.

Most standard resources not covered above (such as continuous integration) =
should be added after bootstrapping. The infrastructure documentation expla=
ins the process.

=3D=3D Initial Committers =3D=3D

List of committers (stating name and an email address) used to bootstrap th=
e community. Mark each which has submitted a contributor license agreement =
(CLA). Existing committers should use their apache.org email address (since=
 they require only appropriate karma).

It is a good idea to submit CLAs at the same time as the proposal. Nothing =
is lost by having a CLA on file at Apache but processing may take some time.

Note this and this. Consider creating a separate section where interested d=
evelopers can express an interest (and possibly leave a brief introduction)=
 or ask them to post to the general list.
Example (OpenJPA): Abe White (awhite at bea dot com) Marc Prud'hommeaux (mp=
rudhom at bea dot com) Patrick Linskey (plinskey at bea dot com) ... Geir M=
agnusson Jr (geirm at apache dot org) * Craig Russell (clr at apache dot or=
g) *


=3D=3D Affiliations =3D=3D

Little bit of a controversial subject. Committers at Apache are individuals=
 and work here on their own behalf. They are judged on their merits not the=
ir affiliations. However, in the spirit of full disclosure, it is useful fo=
r any current affiliations which may effect the perceived independence of t=
he initial committers to be listed openly at the start.

For example, those in salaried positions whose job is to work on the projec=
t should list their affiliation. Having this list helps to judge how much d=
iversity exists in the initial list and so how much work there is to do.

This is best done in a separate section away from the committers list.

Only the affiliations of committers on the initial bootstrap list are relev=
ant. These committers have not been added by the usual meritocratic process=
. It is strongly recommended that the once a project is bootstrapped, devel=
opers are judged by their contributions and not by their background. This l=
ist should not be maintained after the bootstrap has been completed.

=3D=3D Sponsors =3D=3D

=3D=3D=3D Champion =3D=3D=3D

The Champion is a person already associated with Apache who leads the propo=
sal process. It is common - but not necessary - for the Champion to also be=
 proposed as a Mentor.

A Champion should be found before the proposal is formally submitted.

=3D=3D=3D Nominated Mentors =3D=3D=3D

Lists eligible (and willing) individuals nominated as Mentors [definition] =
for the candidate.

It is common for additional Mentors to volunteer their services during the =
development of the proposal. The number of Mentors for a Podling is limited=
 only by the energy and interest of those eligible to Mentor. Three Mentors=
 gives a quorum and allows a Podling more autonomy. The current consensus i=
s that three or more Mentors makes the incubation process run more smoothly.

Note that since Mentors are appointed by the Incubator PMC at the end of th=
e acceptance process, they have no formal role until the proposal is accept=
ed. But informal enthusiasm from nominee Mentors is taken as a good sign.

There is no restriction on the number of informal mentors (note the small m=
) that a Podling may have. These can be very useful but have no formal role=
 in the process.

=3D=3D=3D Sponsoring Entity =3D=3D=3D

The Sponsor is the organizational unit within Apache taking responsibility =
for this proposal. The sponsoring entity can be:

    * the Apache Board
    * the Incubator
    * another Apache project

The PMC for the appropriate project will decide whether to sponsor (by a vo=
te). Unless there are strong links to an existing Apache project, it is rec=
ommended that the proposal asks that the Incubator for sponsorship.

Note that the final destination within the Apache organizational structure =
will be decided upon graduation.