Ideas for Growing the Concerted Community

[Chris Nauroth <cn...@hortonworks.com>]

After the recent incubator-general@ thread about lack of Concerted project activity, I decided to take stock of everything in the project right now.  I tried to approach this from the perspective of an eager volunteer who wants to contribute to a new project.  I'd like to offer a few suggestions.  I'm hopeful that implementing some of these ideas would attract contributors and boost momentum in the project.

Community building might be the most critical aspect right now, because a larger community would spread the effort and prevent bottlenecks when individuals in the community become too busy to participate for some time.  (That's completely understandable and natural BTW.  Even major contributors on the biggest projects have quiet periods when work or other life responsibilities take them away from Apache.)

1. Focus work on the website.  It's still an empty placeholder right now.  This is the first place those eager volunteers will go to see if this is the project where they want to participate.  It also helps keep existing contributors focused on a shared vision.  This is marketing work to some degree, which isn't fun for engineers, but it's important.  :-)  From a quick scan of the CONCERTED-1 pull request, it looks like there is a great start in progress.

2. Adding some kind of user guide would help make the project more concrete too.  I find that my initial read of a project's high-level architecture, examples and API docs are important for stirring my own excitement.  If that initial contact goes well, then it might inspire me to use the project or even contribute to it.  If Concerted is a do-it-yourself kit for building custom in-memory data stores, then one approach would be to show a working end-to-end example of a very simple application built on Concerted.  Maybe the codebase isn't ready for that yet, but think about moving towards something like that.

3. I see you have started a project roadmap, which is great.  If you can expand on that and describe specific features the community plans to implement, then that would help contributors understand if they can help.  I know documentation isn't the most enjoyable part of software engineering, but I've found that it's very important in open source development, where you won't have the benefit of daily face-to-face contact with all of your teammates.

4. There had been mention in the past of prep work involving merging back private forks and refactoring.  From what I can tell now, this either has not happened yet, or the effort is happening privately.  If it's happening privately, then is there any chance of moving that work publicly into Apache?  For example, if someone added an alternative data structure in a private fork, then you could track the merge effort in an Apache Concerted JIRA that describes the proposed data structure.

5. The lack of comments in the code may be a barrier for some people approaching and understanding the project.  Consider doing a pass over the current codebase just adding API documentation.

6. For any work done, remember to track the effort in an Apache JIRA.  Having a backlog of open, unassigned JIRA issues is a signal to contributors that there is an opportunity for them to help.  It gives them a chance to pick up an issue, start working and explore how the project and its community operate.  Newbie issues, which are very small in scope, are important as an entry point for new contributors.

--Chris Nauroth

Re: Ideas for Growing the Concerted Community

[Gaurav Shukla <gs...@gmail.com>]

I haven't signed the icla yet. Moreover I am traveling right now.
On Jan 13, 2016 6:33 PM, "Atri Sharma" <at...@gmail.com> wrote:

> Why don't you go ahead and commit it?
>
>
> On Wed, Jan 13, 2016 at 6:30 PM, Gaurav Shukla <gs...@gmail.com>
> wrote:
>
> > How about we start with the website ?
> > On Jan 13, 2016 6:09 PM, "Atri Sharma" <at...@gmail.com> wrote:
> >
> > > Thanks Julian and Chris!
> > >
> > > Let us put these points into action. Yay for Concerted community
> growth.
> > >
> > > Regards,
> > >
> > > Atri
> > >
> > > On Wed, Jan 13, 2016 at 6:49 AM, Julian Hyde <jh...@apache.org> wrote:
> > >
> > > > Thank you Chris; this is great. I'll add a couple:
> > > >
> > > > 7. Demonstrate public activity! For the purposes of building
> > > > community, private activity might as well not be happening. The best
> > > > place to demonstrate activity is on the mailing list. Start
> > > > discussions, send messages describing how your work on the code is
> > > > going (even if the work is in private). Think aloud, even if your
> > > > thoughts are not answered.
> > > >
> > > > 8. Twitter is another place to demonstrate activity. You'll probably
> > > > want to create an ApacheConcerted twitter handle, and use it to
> engage
> > > > with your community, announcing everything that's the slightest bit
> > > > newsworthy. People tend to forward tweets, and that gives you a lot
> of
> > > > reach in finding a community.
> > > >
> > > > Julian
> > > >
> > > >
> > > >
> > > > On Tue, Jan 12, 2016 at 2:21 PM, Chris Nauroth <
> > cnauroth@hortonworks.com
> > > >
> > > > wrote:
> > > > > After the recent incubator-general@ thread about lack of Concerted
> > > > project activity, I decided to take stock of everything in the
> project
> > > > right now.  I tried to approach this from the perspective of an eager
> > > > volunteer who wants to contribute to a new project.  I'd like to
> offer
> > a
> > > > few suggestions.  I'm hopeful that implementing some of these ideas
> > would
> > > > attract contributors and boost momentum in the project.
> > > > >
> > > > > Community building might be the most critical aspect right now,
> > because
> > > > a larger community would spread the effort and prevent bottlenecks
> when
> > > > individuals in the community become too busy to participate for some
> > > time.
> > > > (That's completely understandable and natural BTW.  Even major
> > > contributors
> > > > on the biggest projects have quiet periods when work or other life
> > > > responsibilities take them away from Apache.)
> > > > >
> > > > > 1. Focus work on the website.  It's still an empty placeholder
> right
> > > > now.  This is the first place those eager volunteers will go to see
> if
> > > this
> > > > is the project where they want to participate.  It also helps keep
> > > existing
> > > > contributors focused on a shared vision.  This is marketing work to
> > some
> > > > degree, which isn't fun for engineers, but it's important.  :-)
> From a
> > > > quick scan of the CONCERTED-1 pull request, it looks like there is a
> > > great
> > > > start in progress.
> > > > >
> > > > > 2. Adding some kind of user guide would help make the project more
> > > > concrete too.  I find that my initial read of a project's high-level
> > > > architecture, examples and API docs are important for stirring my own
> > > > excitement.  If that initial contact goes well, then it might inspire
> > me
> > > to
> > > > use the project or even contribute to it.  If Concerted is a
> > > do-it-yourself
> > > > kit for building custom in-memory data stores, then one approach
> would
> > be
> > > > to show a working end-to-end example of a very simple application
> built
> > > on
> > > > Concerted.  Maybe the codebase isn't ready for that yet, but think
> > about
> > > > moving towards something like that.
> > > > >
> > > > > 3. I see you have started a project roadmap, which is great.  If
> you
> > > can
> > > > expand on that and describe specific features the community plans to
> > > > implement, then that would help contributors understand if they can
> > help.
> > > > I know documentation isn't the most enjoyable part of software
> > > engineering,
> > > > but I've found that it's very important in open source development,
> > where
> > > > you won't have the benefit of daily face-to-face contact with all of
> > your
> > > > teammates.
> > > > >
> > > > > 4. There had been mention in the past of prep work involving
> merging
> > > > back private forks and refactoring.  From what I can tell now, this
> > > either
> > > > has not happened yet, or the effort is happening privately.  If it's
> > > > happening privately, then is there any chance of moving that work
> > > publicly
> > > > into Apache?  For example, if someone added an alternative data
> > structure
> > > > in a private fork, then you could track the merge effort in an Apache
> > > > Concerted JIRA that describes the proposed data structure.
> > > > >
> > > > > 5. The lack of comments in the code may be a barrier for some
> people
> > > > approaching and understanding the project.  Consider doing a pass
> over
> > > the
> > > > current codebase just adding API documentation.
> > > > >
> > > > > 6. For any work done, remember to track the effort in an Apache
> JIRA.
> > > > Having a backlog of open, unassigned JIRA issues is a signal to
> > > > contributors that there is an opportunity for them to help.  It gives
> > > them
> > > > a chance to pick up an issue, start working and explore how the
> project
> > > and
> > > > its community operate.  Newbie issues, which are very small in scope,
> > are
> > > > important as an entry point for new contributors.
> > > > >
> > > > > --Chris Nauroth
> > > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Atri
> > > *l'apprenant*
> > >
> >
>
>
>
> --
> Regards,
>
> Atri
> *l'apprenant*
>

Re: Ideas for Growing the Concerted Community

[Atri Sharma <at...@gmail.com>]

Why don't you go ahead and commit it?


On Wed, Jan 13, 2016 at 6:30 PM, Gaurav Shukla <gs...@gmail.com> wrote:

> How about we start with the website ?
> On Jan 13, 2016 6:09 PM, "Atri Sharma" <at...@gmail.com> wrote:
>
> > Thanks Julian and Chris!
> >
> > Let us put these points into action. Yay for Concerted community growth.
> >
> > Regards,
> >
> > Atri
> >
> > On Wed, Jan 13, 2016 at 6:49 AM, Julian Hyde <jh...@apache.org> wrote:
> >
> > > Thank you Chris; this is great. I'll add a couple:
> > >
> > > 7. Demonstrate public activity! For the purposes of building
> > > community, private activity might as well not be happening. The best
> > > place to demonstrate activity is on the mailing list. Start
> > > discussions, send messages describing how your work on the code is
> > > going (even if the work is in private). Think aloud, even if your
> > > thoughts are not answered.
> > >
> > > 8. Twitter is another place to demonstrate activity. You'll probably
> > > want to create an ApacheConcerted twitter handle, and use it to engage
> > > with your community, announcing everything that's the slightest bit
> > > newsworthy. People tend to forward tweets, and that gives you a lot of
> > > reach in finding a community.
> > >
> > > Julian
> > >
> > >
> > >
> > > On Tue, Jan 12, 2016 at 2:21 PM, Chris Nauroth <
> cnauroth@hortonworks.com
> > >
> > > wrote:
> > > > After the recent incubator-general@ thread about lack of Concerted
> > > project activity, I decided to take stock of everything in the project
> > > right now.  I tried to approach this from the perspective of an eager
> > > volunteer who wants to contribute to a new project.  I'd like to offer
> a
> > > few suggestions.  I'm hopeful that implementing some of these ideas
> would
> > > attract contributors and boost momentum in the project.
> > > >
> > > > Community building might be the most critical aspect right now,
> because
> > > a larger community would spread the effort and prevent bottlenecks when
> > > individuals in the community become too busy to participate for some
> > time.
> > > (That's completely understandable and natural BTW.  Even major
> > contributors
> > > on the biggest projects have quiet periods when work or other life
> > > responsibilities take them away from Apache.)
> > > >
> > > > 1. Focus work on the website.  It's still an empty placeholder right
> > > now.  This is the first place those eager volunteers will go to see if
> > this
> > > is the project where they want to participate.  It also helps keep
> > existing
> > > contributors focused on a shared vision.  This is marketing work to
> some
> > > degree, which isn't fun for engineers, but it's important.  :-)  From a
> > > quick scan of the CONCERTED-1 pull request, it looks like there is a
> > great
> > > start in progress.
> > > >
> > > > 2. Adding some kind of user guide would help make the project more
> > > concrete too.  I find that my initial read of a project's high-level
> > > architecture, examples and API docs are important for stirring my own
> > > excitement.  If that initial contact goes well, then it might inspire
> me
> > to
> > > use the project or even contribute to it.  If Concerted is a
> > do-it-yourself
> > > kit for building custom in-memory data stores, then one approach would
> be
> > > to show a working end-to-end example of a very simple application built
> > on
> > > Concerted.  Maybe the codebase isn't ready for that yet, but think
> about
> > > moving towards something like that.
> > > >
> > > > 3. I see you have started a project roadmap, which is great.  If you
> > can
> > > expand on that and describe specific features the community plans to
> > > implement, then that would help contributors understand if they can
> help.
> > > I know documentation isn't the most enjoyable part of software
> > engineering,
> > > but I've found that it's very important in open source development,
> where
> > > you won't have the benefit of daily face-to-face contact with all of
> your
> > > teammates.
> > > >
> > > > 4. There had been mention in the past of prep work involving merging
> > > back private forks and refactoring.  From what I can tell now, this
> > either
> > > has not happened yet, or the effort is happening privately.  If it's
> > > happening privately, then is there any chance of moving that work
> > publicly
> > > into Apache?  For example, if someone added an alternative data
> structure
> > > in a private fork, then you could track the merge effort in an Apache
> > > Concerted JIRA that describes the proposed data structure.
> > > >
> > > > 5. The lack of comments in the code may be a barrier for some people
> > > approaching and understanding the project.  Consider doing a pass over
> > the
> > > current codebase just adding API documentation.
> > > >
> > > > 6. For any work done, remember to track the effort in an Apache JIRA.
> > > Having a backlog of open, unassigned JIRA issues is a signal to
> > > contributors that there is an opportunity for them to help.  It gives
> > them
> > > a chance to pick up an issue, start working and explore how the project
> > and
> > > its community operate.  Newbie issues, which are very small in scope,
> are
> > > important as an entry point for new contributors.
> > > >
> > > > --Chris Nauroth
> > >
> >
> >
> >
> > --
> > Regards,
> >
> > Atri
> > *l'apprenant*
> >
>



-- 
Regards,

Atri
*l'apprenant*

Re: Ideas for Growing the Concerted Community

[Gaurav Shukla <gs...@gmail.com>]

How about we start with the website ?
On Jan 13, 2016 6:09 PM, "Atri Sharma" <at...@gmail.com> wrote:

> Thanks Julian and Chris!
>
> Let us put these points into action. Yay for Concerted community growth.
>
> Regards,
>
> Atri
>
> On Wed, Jan 13, 2016 at 6:49 AM, Julian Hyde <jh...@apache.org> wrote:
>
> > Thank you Chris; this is great. I'll add a couple:
> >
> > 7. Demonstrate public activity! For the purposes of building
> > community, private activity might as well not be happening. The best
> > place to demonstrate activity is on the mailing list. Start
> > discussions, send messages describing how your work on the code is
> > going (even if the work is in private). Think aloud, even if your
> > thoughts are not answered.
> >
> > 8. Twitter is another place to demonstrate activity. You'll probably
> > want to create an ApacheConcerted twitter handle, and use it to engage
> > with your community, announcing everything that's the slightest bit
> > newsworthy. People tend to forward tweets, and that gives you a lot of
> > reach in finding a community.
> >
> > Julian
> >
> >
> >
> > On Tue, Jan 12, 2016 at 2:21 PM, Chris Nauroth <cnauroth@hortonworks.com
> >
> > wrote:
> > > After the recent incubator-general@ thread about lack of Concerted
> > project activity, I decided to take stock of everything in the project
> > right now.  I tried to approach this from the perspective of an eager
> > volunteer who wants to contribute to a new project.  I'd like to offer a
> > few suggestions.  I'm hopeful that implementing some of these ideas would
> > attract contributors and boost momentum in the project.
> > >
> > > Community building might be the most critical aspect right now, because
> > a larger community would spread the effort and prevent bottlenecks when
> > individuals in the community become too busy to participate for some
> time.
> > (That's completely understandable and natural BTW.  Even major
> contributors
> > on the biggest projects have quiet periods when work or other life
> > responsibilities take them away from Apache.)
> > >
> > > 1. Focus work on the website.  It's still an empty placeholder right
> > now.  This is the first place those eager volunteers will go to see if
> this
> > is the project where they want to participate.  It also helps keep
> existing
> > contributors focused on a shared vision.  This is marketing work to some
> > degree, which isn't fun for engineers, but it's important.  :-)  From a
> > quick scan of the CONCERTED-1 pull request, it looks like there is a
> great
> > start in progress.
> > >
> > > 2. Adding some kind of user guide would help make the project more
> > concrete too.  I find that my initial read of a project's high-level
> > architecture, examples and API docs are important for stirring my own
> > excitement.  If that initial contact goes well, then it might inspire me
> to
> > use the project or even contribute to it.  If Concerted is a
> do-it-yourself
> > kit for building custom in-memory data stores, then one approach would be
> > to show a working end-to-end example of a very simple application built
> on
> > Concerted.  Maybe the codebase isn't ready for that yet, but think about
> > moving towards something like that.
> > >
> > > 3. I see you have started a project roadmap, which is great.  If you
> can
> > expand on that and describe specific features the community plans to
> > implement, then that would help contributors understand if they can help.
> > I know documentation isn't the most enjoyable part of software
> engineering,
> > but I've found that it's very important in open source development, where
> > you won't have the benefit of daily face-to-face contact with all of your
> > teammates.
> > >
> > > 4. There had been mention in the past of prep work involving merging
> > back private forks and refactoring.  From what I can tell now, this
> either
> > has not happened yet, or the effort is happening privately.  If it's
> > happening privately, then is there any chance of moving that work
> publicly
> > into Apache?  For example, if someone added an alternative data structure
> > in a private fork, then you could track the merge effort in an Apache
> > Concerted JIRA that describes the proposed data structure.
> > >
> > > 5. The lack of comments in the code may be a barrier for some people
> > approaching and understanding the project.  Consider doing a pass over
> the
> > current codebase just adding API documentation.
> > >
> > > 6. For any work done, remember to track the effort in an Apache JIRA.
> > Having a backlog of open, unassigned JIRA issues is a signal to
> > contributors that there is an opportunity for them to help.  It gives
> them
> > a chance to pick up an issue, start working and explore how the project
> and
> > its community operate.  Newbie issues, which are very small in scope, are
> > important as an entry point for new contributors.
> > >
> > > --Chris Nauroth
> >
>
>
>
> --
> Regards,
>
> Atri
> *l'apprenant*
>

Re: Ideas for Growing the Concerted Community

[Atri Sharma <at...@gmail.com>]

Thanks Julian and Chris!

Let us put these points into action. Yay for Concerted community growth.

Regards,

Atri

On Wed, Jan 13, 2016 at 6:49 AM, Julian Hyde <jh...@apache.org> wrote:

> Thank you Chris; this is great. I'll add a couple:
>
> 7. Demonstrate public activity! For the purposes of building
> community, private activity might as well not be happening. The best
> place to demonstrate activity is on the mailing list. Start
> discussions, send messages describing how your work on the code is
> going (even if the work is in private). Think aloud, even if your
> thoughts are not answered.
>
> 8. Twitter is another place to demonstrate activity. You'll probably
> want to create an ApacheConcerted twitter handle, and use it to engage
> with your community, announcing everything that's the slightest bit
> newsworthy. People tend to forward tweets, and that gives you a lot of
> reach in finding a community.
>
> Julian
>
>
>
> On Tue, Jan 12, 2016 at 2:21 PM, Chris Nauroth <cn...@hortonworks.com>
> wrote:
> > After the recent incubator-general@ thread about lack of Concerted
> project activity, I decided to take stock of everything in the project
> right now.  I tried to approach this from the perspective of an eager
> volunteer who wants to contribute to a new project.  I'd like to offer a
> few suggestions.  I'm hopeful that implementing some of these ideas would
> attract contributors and boost momentum in the project.
> >
> > Community building might be the most critical aspect right now, because
> a larger community would spread the effort and prevent bottlenecks when
> individuals in the community become too busy to participate for some time.
> (That's completely understandable and natural BTW.  Even major contributors
> on the biggest projects have quiet periods when work or other life
> responsibilities take them away from Apache.)
> >
> > 1. Focus work on the website.  It's still an empty placeholder right
> now.  This is the first place those eager volunteers will go to see if this
> is the project where they want to participate.  It also helps keep existing
> contributors focused on a shared vision.  This is marketing work to some
> degree, which isn't fun for engineers, but it's important.  :-)  From a
> quick scan of the CONCERTED-1 pull request, it looks like there is a great
> start in progress.
> >
> > 2. Adding some kind of user guide would help make the project more
> concrete too.  I find that my initial read of a project's high-level
> architecture, examples and API docs are important for stirring my own
> excitement.  If that initial contact goes well, then it might inspire me to
> use the project or even contribute to it.  If Concerted is a do-it-yourself
> kit for building custom in-memory data stores, then one approach would be
> to show a working end-to-end example of a very simple application built on
> Concerted.  Maybe the codebase isn't ready for that yet, but think about
> moving towards something like that.
> >
> > 3. I see you have started a project roadmap, which is great.  If you can
> expand on that and describe specific features the community plans to
> implement, then that would help contributors understand if they can help.
> I know documentation isn't the most enjoyable part of software engineering,
> but I've found that it's very important in open source development, where
> you won't have the benefit of daily face-to-face contact with all of your
> teammates.
> >
> > 4. There had been mention in the past of prep work involving merging
> back private forks and refactoring.  From what I can tell now, this either
> has not happened yet, or the effort is happening privately.  If it's
> happening privately, then is there any chance of moving that work publicly
> into Apache?  For example, if someone added an alternative data structure
> in a private fork, then you could track the merge effort in an Apache
> Concerted JIRA that describes the proposed data structure.
> >
> > 5. The lack of comments in the code may be a barrier for some people
> approaching and understanding the project.  Consider doing a pass over the
> current codebase just adding API documentation.
> >
> > 6. For any work done, remember to track the effort in an Apache JIRA.
> Having a backlog of open, unassigned JIRA issues is a signal to
> contributors that there is an opportunity for them to help.  It gives them
> a chance to pick up an issue, start working and explore how the project and
> its community operate.  Newbie issues, which are very small in scope, are
> important as an entry point for new contributors.
> >
> > --Chris Nauroth
>



-- 
Regards,

Atri
*l'apprenant*

Re: Ideas for Growing the Concerted Community

[Julian Hyde <jh...@apache.org>]

Thank you Chris; this is great. I'll add a couple:

7. Demonstrate public activity! For the purposes of building
community, private activity might as well not be happening. The best
place to demonstrate activity is on the mailing list. Start
discussions, send messages describing how your work on the code is
going (even if the work is in private). Think aloud, even if your
thoughts are not answered.

8. Twitter is another place to demonstrate activity. You'll probably
want to create an ApacheConcerted twitter handle, and use it to engage
with your community, announcing everything that's the slightest bit
newsworthy. People tend to forward tweets, and that gives you a lot of
reach in finding a community.

Julian



On Tue, Jan 12, 2016 at 2:21 PM, Chris Nauroth <cn...@hortonworks.com> wrote:
> After the recent incubator-general@ thread about lack of Concerted project activity, I decided to take stock of everything in the project right now.  I tried to approach this from the perspective of an eager volunteer who wants to contribute to a new project.  I'd like to offer a few suggestions.  I'm hopeful that implementing some of these ideas would attract contributors and boost momentum in the project.
>
> Community building might be the most critical aspect right now, because a larger community would spread the effort and prevent bottlenecks when individuals in the community become too busy to participate for some time.  (That's completely understandable and natural BTW.  Even major contributors on the biggest projects have quiet periods when work or other life responsibilities take them away from Apache.)
>
> 1. Focus work on the website.  It's still an empty placeholder right now.  This is the first place those eager volunteers will go to see if this is the project where they want to participate.  It also helps keep existing contributors focused on a shared vision.  This is marketing work to some degree, which isn't fun for engineers, but it's important.  :-)  From a quick scan of the CONCERTED-1 pull request, it looks like there is a great start in progress.
>
> 2. Adding some kind of user guide would help make the project more concrete too.  I find that my initial read of a project's high-level architecture, examples and API docs are important for stirring my own excitement.  If that initial contact goes well, then it might inspire me to use the project or even contribute to it.  If Concerted is a do-it-yourself kit for building custom in-memory data stores, then one approach would be to show a working end-to-end example of a very simple application built on Concerted.  Maybe the codebase isn't ready for that yet, but think about moving towards something like that.
>
> 3. I see you have started a project roadmap, which is great.  If you can expand on that and describe specific features the community plans to implement, then that would help contributors understand if they can help.  I know documentation isn't the most enjoyable part of software engineering, but I've found that it's very important in open source development, where you won't have the benefit of daily face-to-face contact with all of your teammates.
>
> 4. There had been mention in the past of prep work involving merging back private forks and refactoring.  From what I can tell now, this either has not happened yet, or the effort is happening privately.  If it's happening privately, then is there any chance of moving that work publicly into Apache?  For example, if someone added an alternative data structure in a private fork, then you could track the merge effort in an Apache Concerted JIRA that describes the proposed data structure.
>
> 5. The lack of comments in the code may be a barrier for some people approaching and understanding the project.  Consider doing a pass over the current codebase just adding API documentation.
>
> 6. For any work done, remember to track the effort in an Apache JIRA.  Having a backlog of open, unassigned JIRA issues is a signal to contributors that there is an opportunity for them to help.  It gives them a chance to pick up an issue, start working and explore how the project and its community operate.  Newbie issues, which are very small in scope, are important as an entry point for new contributors.
>
> --Chris Nauroth