Re: Question about other's experience with the benefits of graduation from the incubator

[Fabian Hueske]

Hi Carin,

Thanks for the question.
Graduation is an important step for every ASF project that all incubating
projects should be working towards.
As others have said, it shows that the community is healthy, growing and
following the Apache Way (public discussions, Apache-compliant releases,
voting in new committers, etc.)

After graduation, the PMC is responsible for the project, e.g., it needs to
check releases, vote on new committers / PMC members, ensure that the
trademark of the project is correctly used, act on security issues, etc.
While being in the incubator, the PPMC is learning all these things but
eventually, the Incubator PMC is responsible.

However, you are asking what are the *benefits* of graduating.

I think there are at least the following three points:

* The community becomes responsible for the project (see above). This is
like the project coming of age.
* Becoming a top-level project is an indicator for the health of the
community and sustainability of the project. It shows that the project is
passed the standards of the incubator.
This can be relevant because often the health of the community is an
important aspect when choosing an open source software to use, include in
an other project or product, or to contribute to.
Although often confused, graduation is no indicator for the
quality/maturity of the code/software.
* The ASF can issue a press statement when a project graduates. This can
give the project some (short-term) exposure on the news and help to spread
the word about the project and attract new users and contributors.

Best,
Fabian

Am Fr., 18. Jan. 2019 um 16:37 Uhr schrieb Carin Meier :

> Hi,
>
> I'm with the MXNet project which is currently in incubation. I had asked
> some questions about incubation on our dev list
>
> https://lists.apache.org/thread.html/2499b18ab2c124db4765a2a2e72868f65363cd5ea08b2ec2d860e1ae@%3Cdev.mxnet.apache.org%3E
> and got some great responses.
>
> Isabel Drost-Fromm encouraged us to share the last question here to get
> some experiences from the other projects that have successfully gone
> through incubation and graduated.
>
> Here is the question:
>
> *What are the benefits of graduation to the project itself and the end
> users? *
>
> Thanks for any feedback.
>
> Best,
> Carin Meier
>

Re: Question about other's experience with the benefits of graduation from the incubator

[Bertrand Delacretaz]

Hi,

On Mon, Jan 21, 2019 at 2:41 PM Fabian Hueske  wrote:
>... Graduation is an important step for every ASF project that all incubating
> projects should be working towards

Absolutely, graduation is a *requirement* for podlings which cannot be
considered optional.

If a podling is unsure whether Apache is the right home for them they
should talk to their mentors and/or to the Incubator PMC to find out
what can be done, and decide to stay or leave, but not linger forever
in the Incubator which is not designed for that.

I don't meant to derail this discussion and it's great to ask these
questions but maybe "what are the benefits of being an Apache project"
is the question that's actually being asked, as graduation is not
optional.

Onwards...thanks for starting this discussion!

-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Proposed process for recognizing *Non-Technical* Contributions

[Roy Lenferink]

I think it is an excellent idea to suggest submitting an ICLA to
contributors when they submit a contribution.
CNCF is using a bot on their GitHub repositories which adds a label to
every pull request whether the contributor has a cla on file [1][2].
More info on this here [3]
The cla label is checked before the PR can be merged.

As we're moving to a broader GitHub integration maybe it is an idea to use
a technology like this as well.
I can foresee a small problem with this, as AFAIK all CLAs are still
processed manually, but correct me if I'm wrong.

What do you think?

[1] http://home.apache.org/~rlenferink/img/cncf-cla-message.png
[2] http://home.apache.org/~rlenferink/img/cncf-cla-reporting.png (last
job: cla/linuxfoundation)
[3]
https://github.com/kubernetes/community/blob/master/CLA.md#the-contributor-license-agreement

- Roy

Op ma 21 jan. 2019 om 07:02 schreef Craig Russell :

>
>
> > On Jan 20, 2019, at 9:52 PM, Craig Russell  wrote:
> >
> > Hi Sharan,
> >
> >> On Jan 13, 2019, at 5:59 AM, Sharan Foga  sha...@apache.org>> wrote:
> >>
> >> Hi Craig
> >>
> >> One thing that we have done in OFBiz is that when a contributor
> requests access to our wiki, we ask them to complete an ICLA before the
> access request is processed. This has helped to capture people who for
> example want to create documentation.
> >
> > This is a terrific idea. I think we should add something to the PMC
> pages about recognizing contributions and asking contributors to file ICLAs.
>
> Thinking about this some more, we might even recommend that the PMC
> actively monitor contributions from non-committers, not just those who
> request access to the wiki; and suggest that they should submit an ICLA.
>
> Craig
> >
> > In addition to the community building and the recognition, filing an
> ICLA has subsequent benefits to the project and the future committer. Just
> as soon as the PMC decides to invite the contributor to become a committer,
> they can finish the process without any delays.
> >
> > I'll propose some updates to the PMC community pages to reflect this.
> >
> > Craig
> >>
> >> We have setup a page with some basic explanations of what an ICLA is
> and why we are asking them to sign one.
> >>
> >> https://s.apache.org/NrGP 
> >>
> >> As well as setting them up with wiki access, we flag them in our Jira
> as part of a contributor group where they can then actually start assigning
> tasks (including the non technical ones) to themselves.
> >>
> >> Perhaps this could be one of the potential suggestions that we could
> include for projects.
> >>
> >> Thanks
> >> Sharan
> >>
> >> On 2019/01/10 15:52:19, Craig Russell  apache@gmail.com>> wrote:
> >>> Hi Sally,
> >>>
>  On Jan 10, 2019, at 12:53 AM, Sally Khudairi  s...@apache.org>> wrote:
> 
> >>> Great writeup and I can wholeheartedly agree with everything except
> this:
> >>>
>  3) All project/committee participants are encouraged to sign an ASF
> ICLA in order to have their contributions recognized.
> >>>
> >>> With my Secretary hat on: It is really a lot of work to process
> non-CLA contributors. So I'd change this to:
> >>>
> >>> 3) All project/committee participants are required to sign an ASF ICLA
> in order to have their contributions recognized.
> >>>
> >>> Normally this will have been done in step 2 but your writeup seems to
> imply that filing an ICLA is optional. My recommendation: not optional.
> >>>
> >>> Regards,
> >>>
> >>> Craig
> >>>
> >>> Craig L Russell
> >>> Secretary, Apache Software Foundation
> >>> c...@apache.org  > http://db.apache.org/jdo  <
> http://db.apache.org/jdo >
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org  dev-unsubscr...@community.apache.org>
> >> For additional commands, e-mail: dev-h...@community.apache.org  dev-h...@community.apache.org>
> > Craig L Russell
> > Secretary, Apache Software Foundation
> > c...@apache.org  http://db.apache.org/jdo <
> http://db.apache.org/jdo>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org  http://db.apache.org/jdo <
> http://db.apache.org/jdo>
>

Re: Proposed process for recognizing *Non-Technical* Contributions

[Mark Thomas]

On 21/01/2019 17:59, Roy Lenferink wrote:
> I think it is an excellent idea to suggest submitting an ICLA to
> contributors when they submit a contribution.

Generally, adding barriers to participation reduces contributions rather
than increases them.

If folks want to submit an CLA then of course they can (and there is no
harm in pointing this out to a new contributor) but it should remain
optional until someone is made a committer.

I'll go further and say that I have seen some projects require CLAs from
contributors for some/all contributions and I think that is adding
unnecessary barriers to participation.

> CNCF is using a bot on their GitHub repositories which adds a label to
> every pull request whether the contributor has a cla on file [1][2].
> More info on this here [3]
> The cla label is checked before the PR can be merged.
> 
> As we're moving to a broader GitHub integration maybe it is an idea to use
> a technology like this as well.

That would make CLAs mandatory and I disagree very strongly with any
move in that direction.

> I can foresee a small problem with this, as AFAIK all CLAs are still
> processed manually, but correct me if I'm wrong.

CLA processing is largely automated and work is in hand to make it more so.

Mark

> 
> What do you think?
> 
> [1] http://home.apache.org/~rlenferink/img/cncf-cla-message.png
> [2] http://home.apache.org/~rlenferink/img/cncf-cla-reporting.png (last
> job: cla/linuxfoundation)
> [3]
> https://github.com/kubernetes/community/blob/master/CLA.md#the-contributor-license-agreement
> 
> - Roy
> 
> Op ma 21 jan. 2019 om 07:02 schreef Craig Russell :
> 
>>
>>
>>> On Jan 20, 2019, at 9:52 PM, Craig Russell  wrote:
>>>
>>> Hi Sharan,
>>>
 On Jan 13, 2019, at 5:59 AM, Sharan Foga > sha...@apache.org>> wrote:

 Hi Craig

 One thing that we have done in OFBiz is that when a contributor
>> requests access to our wiki, we ask them to complete an ICLA before the
>> access request is processed. This has helped to capture people who for
>> example want to create documentation.
>>>
>>> This is a terrific idea. I think we should add something to the PMC
>> pages about recognizing contributions and asking contributors to file ICLAs.
>>
>> Thinking about this some more, we might even recommend that the PMC
>> actively monitor contributions from non-committers, not just those who
>> request access to the wiki; and suggest that they should submit an ICLA.
>>
>> Craig
>>>
>>> In addition to the community building and the recognition, filing an
>> ICLA has subsequent benefits to the project and the future committer. Just
>> as soon as the PMC decides to invite the contributor to become a committer,
>> they can finish the process without any delays.
>>>
>>> I'll propose some updates to the PMC community pages to reflect this.
>>>
>>> Craig

 We have setup a page with some basic explanations of what an ICLA is
>> and why we are asking them to sign one.

 https://s.apache.org/NrGP 

 As well as setting them up with wiki access, we flag them in our Jira
>> as part of a contributor group where they can then actually start assigning
>> tasks (including the non technical ones) to themselves.

 Perhaps this could be one of the potential suggestions that we could
>> include for projects.

 Thanks
 Sharan

 On 2019/01/10 15:52:19, Craig Russell > apache@gmail.com>> wrote:
> Hi Sally,
>
>> On Jan 10, 2019, at 12:53 AM, Sally Khudairi > s...@apache.org>> wrote:
>>
> Great writeup and I can wholeheartedly agree with everything except
>> this:
>
>> 3) All project/committee participants are encouraged to sign an ASF
>> ICLA in order to have their contributions recognized.
>
> With my Secretary hat on: It is really a lot of work to process
>> non-CLA contributors. So I'd change this to:
>
> 3) All project/committee participants are required to sign an ASF ICLA
>> in order to have their contributions recognized.
>
> Normally this will have been done in step 2 but your writeup seems to
>> imply that filing an ICLA is optional. My recommendation: not optional.
>
> Regards,
>
> Craig
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org   c...@apache.org>> http://db.apache.org/jdo  <
>> http://db.apache.org/jdo >
>

 -
 To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > dev-unsubscr...@community.apache.org>
 For additional commands, e-mail: dev-h...@community.apache.org > dev-h...@community.apache.org>
>>> Craig L Russell
>>> Secretary, Apache Software Foundation
>>> c...@apache.org  http://db.apache.org/jdo <
>> http://db.apache.org/jdo>
>> Craig L Russell
>> Secret

Re: Proposed process for recognizing *Non-Technical* Contributions

[Joan Touzet]

"Mark Thomas"  wrote:
> On 21/01/2019 17:59, Roy Lenferink wrote:
> > CNCF is using a bot on their GitHub repositories which adds a label
> > to
> > every pull request whether the contributor has a cla on file
> > [1][2].
> > More info on this here [3]
> > The cla label is checked before the PR can be merged.
> > 
> > As we're moving to a broader GitHub integration maybe it is an idea
> > to use
> > a technology like this as well.
> 
> That would make CLAs mandatory and I disagree very strongly with any
> move in that direction.

Absolutely agree with Mark here.

The way we see it, when we receive a PR on an Apache repo from a random 
ontributor that is merged by a committer, it is the committer who is
responsible for the code, and the committer who has already signed
the CLA.

This is no different from when we used to receive .patch files by
mailing list or JIRA. They arrived plenty of times from people
who didn't have signed CLAs or commit bits. It was the committer's
responsibility to review and accept the code, and it was their
liability if something went wrong. This extends to any version
controlled asset.

Wikis are weird - we've dropped use of ours for most things, since
there was misleading, confusing, and outdated content in ours, chiefly
because there was no Review-Then-Commit model. GitHub PRs are RTC,
not CTR, so the safeguard is built in. I can see the desire for a
CLA to be signed when there is only a CTR process available.

Communities that require CLAs to be signed before code can even be
proposed for merging in a pull request, emailed patch or simlar
definitely show a lower rate of participation than those who don't
in my experience.

-Joan

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Question about other's experience with the benefits of graduation from the incubator

[Carin Meier]

Thanks for your feedback. For context, we are *very* interested in
graduating. As one of our steps forward to our goal, we are investigating
this question as a way of understanding as a group where we are headed and
why.

The answers and feedback help us our enrich and solidify our understanding.

- Carin

On Mon, Jan 21, 2019 at 10:38 AM Bertrand Delacretaz 
wrote:

> Hi,
>
> On Mon, Jan 21, 2019 at 2:41 PM Fabian Hueske  wrote:
> >... Graduation is an important step for every ASF project that all
> incubating
> > projects should be working towards
>
> Absolutely, graduation is a *requirement* for podlings which cannot be
> considered optional.
>
> If a podling is unsure whether Apache is the right home for them they
> should talk to their mentors and/or to the Incubator PMC to find out
> what can be done, and decide to stay or leave, but not linger forever
> in the Incubator which is not designed for that.
>
> I don't meant to derail this discussion and it's great to ask these
> questions but maybe "what are the benefits of being an Apache project"
> is the question that's actually being asked, as graduation is not
> optional.
>
> Onwards...thanks for starting this discussion!
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Proposed process for recognizing *Non-Technical* Contributions

[Roy Lenferink]

Op ma 21 jan. 2019 om 20:25 schreef Joan Touzet :

> "Mark Thomas"  wrote:
> > On 21/01/2019 17:59, Roy Lenferink wrote:
> > > CNCF is using a bot on their GitHub repositories which adds a label
> > > to
> > > every pull request whether the contributor has a cla on file
> > > [1][2].
> > > More info on this here [3]
> > > The cla label is checked before the PR can be merged.
> > >
> > > As we're moving to a broader GitHub integration maybe it is an idea
> > > to use
> > > a technology like this as well.
> >
> > That would make CLAs mandatory and I disagree very strongly with any
> > move in that direction.
>
> Absolutely agree with Mark here.
>

That indeed is a huge disadvantage as well. It isn't that I'm all for
requiring CLAs,
as it will block simple bug fixes as well, but at least I think it would be
good to
maybe enhance the process, e.g. a bot adding a "cla:no" or "cla:yes" label
doesn't harm anyone, and if a contributor is submitting a PR with a
sufficient
amount of changes it makes it easier for the committer to verify whether
the
contributor has a CLA filed.

But that's just my opinion. It's not a problem at all if anyone thinks
differently.
I'm just trying to figure out what would be best ;)


>
> The way we see it, when we receive a PR on an Apache repo from a random
> contributor that is merged by a committer, it is the committer who is
> responsible for the code, and the committer who has already signed
> the CLA.
>

IMO this is not completely true. I think it indeed is the responsibility of
the committer
to check whether a contributor needs to file an ICLA, but it still is the
contributor who actually committed the change and it's the contributor's
name
and e-mail that will be listed as author for the commit. The ASF committer
just
simply merged the commit back to the repo (knowing he has to check licenses
for used technology etc..).

But again, please correct me if I'm wrong.


>
> This is no different from when we used to receive .patch files by
> mailing list or JIRA. They arrived plenty of times from people
> who didn't have signed CLAs or commit bits. It was the committer's
> responsibility to review and accept the code, and it was their
> liability if something went wrong. This extends to any version
> controlled asset.
>
> Wikis are weird - we've dropped use of ours for most things, since
> there was misleading, confusing, and outdated content in ours, chiefly
> because there was no Review-Then-Commit model. GitHub PRs are RTC,
> not CTR, so the safeguard is built in. I can see the desire for a
> CLA to be signed when there is only a CTR process available.
>
> Communities that require CLAs to be signed before code can even be
> proposed for merging in a pull request, emailed patch or simlar
> definitely show a lower rate of participation than those who don't
> in my experience.
>
> -Joan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Contributing an updated slide deck

[Aizhamal Nurmamat kyzy]

Hello everyone,

I recently shared a slide deck with an introduction to "The Apache Way" in
this mailing list. I've got some very valuable feedback from community
members, and I have incorporated some into the slides. The updated deck is
here:

https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.p


The material is intended to be used by anyone for their presentations. I am
not a committer, but I was wondering if it would be of decent enough
quality to be included in the slides section[2]? If it is, is there a
committer in this group that could help me do that change?

Thanks to everyone for your help and feedback!
-A.

[1]
https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.p

[2] https://community.apache.org/speakers/slides.html

--

Re: Contributing an updated slide deck

[Michael Pavino]

michaelpav...@gmail.com

On Tue, Jan 22, 2019, 12:20 PM Aizhamal Nurmamat kyzy
 Hello everyone,
>
> I recently shared a slide deck with an introduction to "The Apache Way" in
> this mailing list. I've got some very valuable feedback from community
> members, and I have incorporated some into the slides. The updated deck is
> here:
>
>
> https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.p
> <
> https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.p
> >
>
> The material is intended to be used by anyone for their presentations. I am
> not a committer, but I was wondering if it would be of decent enough
> quality to be included in the slides section[2]? If it is, is there a
> committer in this group that could help me do that change?
>
> Thanks to everyone for your help and feedback!
> -A.
>
> [1]
>
> https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.p
> <
> https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.p
> >
> [2] https://community.apache.org/speakers/slides.html
>
> --
>

Re: Contributing an updated slide deck

[Dave Fisher]

Cool. Some comments.

Side 5

PMC Chairs are Vice Presidents of the project and officers of the Foundation.

Slide 8

In my opinion, Vendor Neutrality is either a 4th Pillar, the Foundation, or an 
adjunct to the “How It Works”. I’m not sure which metaphor is best, but the 
topic should be covered.

Slide 12

In the Incubator we like to guide podlings to delay users@ until there is a 
proven need. Reason is that having just dev@ can be important to all interested 
devs and new users to their experience with the code and developing community.

Also, you don’t mention commits@ where most project direct various code changes 
and other logging. The usual impetus for that that dev@ is getting hammered 
with these emails. That said the PMC is expected to subscribe to and follow a 
commits@ mailing list.

Slide 13 

If the PMC Chair is negligent in reporting duties to the Board then the other 
PMC members can step in and submit the quarterly board report. Beyond the duty 
to the foundation as an officer PMC Chairs have no more responsibilities or 
rights than the other PMC members. In a sense their duties are more secretarial 
than leadership. The ASF goes for a flat hierarchy as much as feasible.

ASF Members do not vote on new Incubator podlings. It works as so (currently) - 
any member can join the Incubator PMC. The Incubator PMC can also elect PMC 
members from people that they have identified as knowledgeable on the Apache 
Way (and likely candidates for Apache Membership at the next annual meeting 
(recently in March)).

Slide 16

You miss voting on new committers and PMC members which is technically your 
“Majority Approval” but culturally is better as “Consensus Approval”. I think 
that the distinction between the two is not so much as you describe. It is more 
that “Consensus” is preferred, but sometimes “Majority” is what you get. I 
think that others will want to debate this point.

Slide 20
Should the escalation point be the code of conduct? That does offer a concrete 
ML to escalate towards.

Slide 21
I think your description of a PMC member applies to Committers as well. For PMC 
members I would discuss binding votes on releases, approving new committers and 
PMC members and managing the project brand. I’m sure that lis tis incomplete.

Sorry, this is way more wordy than I intended. Take it as you wish.

Regards,
Dave


> On Jan 21, 2019, at 8:20 PM, Aizhamal Nurmamat kyzy 
>  wrote:
> 
> Hello everyone,
> 
> I recently shared a slide deck with an introduction to "The Apache Way" in
> this mailing list. I've got some very valuable feedback from community
> members, and I have incorporated some into the slides. The updated deck is
> here:
> 
> https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.p
> 
> 
> The material is intended to be used by anyone for their presentations. I am
> not a committer, but I was wondering if it would be of decent enough
> quality to be included in the slides section[2]? If it is, is there a
> committer in this group that could help me do that change?
> 
> Thanks to everyone for your help and feedback!
> -A.
> 
> [1]
> https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.p
> 
> [2] https://community.apache.org/speakers/slides.html
> 
> --


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Question about other's experience with the benefits of graduation from the incubator

[Jun Rao]

Hi, Carin,

This is Jun and I have worked on Apache Cassandra and Kafka.

To me, the benefits of ASF and/or becoming a topic level project are the
following.
1. ASF carries a strong brand name. Many enterprises are much more
comfortable with adopting software that's from a top-level ASF project than
just a github project.
2. ASF helps consolidate development efforts. Once there is a top-level
Apache project in one area, it tends to reduce the number of cloned/forked
variants.
3. Openness in ASF can lead to more innovations in the software in the long
run.
4. There are examples that you can build a successful business on Apache
projects. While the per unit price of open source software tends to be
lower than proprietary software, ASF helps compensate for that by reducing
the customer acquisition cost and the software development cost for a
vendor, and by increasing the user base.

You didn't ask the for the downside specifically, but I will list a few
potential ones.
1. ASF has a set of rules. Fully understanding all of them may not be easy
since not all them are documented and explained clearly.
2. ASF has a large community. Sometimes different members can have
different opinions, which could mean longer time for decision-making.

Thanks,

Jun


On Mon, Jan 21, 2019 at 11:38 AM Carin Meier  wrote:

> Thanks for your feedback. For context, we are *very* interested in
> graduating. As one of our steps forward to our goal, we are investigating
> this question as a way of understanding as a group where we are headed and
> why.
>
> The answers and feedback help us our enrich and solidify our understanding.
>
> - Carin
>
> On Mon, Jan 21, 2019 at 10:38 AM Bertrand Delacretaz <
> bdelacre...@apache.org>
> wrote:
>
> > Hi,
> >
> > On Mon, Jan 21, 2019 at 2:41 PM Fabian Hueske  wrote:
> > >... Graduation is an important step for every ASF project that all
> > incubating
> > > projects should be working towards
> >
> > Absolutely, graduation is a *requirement* for podlings which cannot be
> > considered optional.
> >
> > If a podling is unsure whether Apache is the right home for them they
> > should talk to their mentors and/or to the Incubator PMC to find out
> > what can be done, and decide to stay or leave, but not linger forever
> > in the Incubator which is not designed for that.
> >
> > I don't meant to derail this discussion and it's great to ask these
> > questions but maybe "what are the benefits of being an Apache project"
> > is the question that's actually being asked, as graduation is not
> > optional.
> >
> > Onwards...thanks for starting this discussion!
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>