community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: Does GSoC help develop communities?
Date Mon, 05 Dec 2016 16:15:56 GMT
Perhaps something for ComDev is to work on engagement with software
developers who don't currently consider themselves part of any ASF
community, but use our software without contributing (much) back.

These are generally more experienced than GSOC students, and while they
won't have as much continual time available, they could contribute in other
ways.

You may them moaning on StackOverflow or at big software conferences.
ApacheCon is nice, but is often preaching to the converted (and their
colleagues they managed to lure along :-).

I would think that many times ASF comitters could be at a more specific
conference or venue for their field, and could easily give an ASF/open
source pep talk to people they meet or present to. Golden opportunity!
Perhaps some Comdev PDFs of a generic flyer with "How does ASF work? Join
us!" could be handy to print out, so they don't have to make up everything
on the spot or beg here for trademark guidance to compose their own ASF
promo material.


Knowing myself and my organisation, we used ASF software for at least 10
years, developing our own open source software. It didn't occur to us to
during that time that perhaps we could (should!) also help out on ASF
software we relied on, like httpd, tomcat, commons, derby, Jena, etc.
No-one told us so, no READMEs or announcements, no people or stands at big
conferences.



Now there is GitHub pull requests, which do significantly lower the
barrier, but many ASF projects still don't say much (or at all) on their
pages and READMEs that this is a welcome contribution path.


Many ASF projects don't explain well enough for outsiders how development
happens. Perhaps it looks as if we are all experts and you need to be
specially invited. Perhaps people sign up to dev@ lists, but get scared by
the open development discussions, thinking "Uh, I don't know enough about
this, it's clearly not for me. And what is this VOTE thing?". We can't
know, because those people are not around.


The information is there, but it is often buried, not linked to from
project home pages and email threads - "everybody knows". For instance I
try to include statements like this in VOTE emails:


> Anyone can participate in testing and voting, not just

committers, please feel free to try out the release candidate
and provide your votes.

How to review a release candidate? https://s.apache.org/review-release



ComDev could help with building a generic pages like "what is a release
candidate and what do I do", "How are decisions made?". This then fits into
the ComDev or ASF blog and could be used as a default link or template for
projects to refer to when voting - it should be more observational than
policy.

Could it make sense for ComDev to (sensitively) contribute patches pr
recommendations to ASF projects in this regard? It should not look like
medling or patronising, just like a pull request with friendly suggestions.

Often I find it is that incubator projects get it right (eventually), while
older projects are comfortably established and are effectively outdated in
respect to the the ComDev maturity model and ASF best practice. (E.g. link
to older mbox mailing list archive, no link to Code of Conduct).

Perhaps ComDev can act like a prpject visitor. (Not auditor or inspector!)
We can make a wiki page with a randomised list of all ASF projects, a quick
checklist (smaller than maturity model) and just go through them one by one
and raise issues/pull requests for any small community encouragement issues
we find. Is that too intrusive?

On 5 Dec 2016 3:26 pm, "Daniel Gruno" <humbedooh@apache.org> wrote:

> On 12/05/2016 03:46 PM, Shane Curcuru wrote:
> > Ulrich Stärk wrote on 12/5/16 9:27 AM:
> >> On 05.12.16 14:30, Daniel Gruno wrote:
> >>> On 12/05/2016 01:41 PM, Ulrich Stärk wrote:
> > ...snip...
> >>> But this goes beyond GSoC in my mind. We should be looking at ALL
> ComDev
> >>> projects and evaluate what we want to keep, what isn't working, and
> what
> >>> needs a do-over. The task of ComDev is to *develop communities*, it
> >>> shouldn't just be a dumping ground for all things cross-project,
> whether
> >>> they work or not. That is at least my opinion.
> >>>
> >>> We try strategies, give them life, see if they work, and if not, we put
> >>> them to sleep or fix them.
> >>
> >> Geez, we are not maximizing for efficiency here (and that coming from a
> management consultant, how
> >> ironic).
> >>
> >> Let me take GSoC as an example again. As long as we have volunteer
> mentors from our communities that
> >> want to mentor students working on their projects than we IMO don't
> need any additional metric or a
> >> certain level of usefulness to justify running the program. Our
> communities think it is important -
> >> otherwise they wouldn't invest the time -, so should we.
> > ...snip...
> >
> > You both have excellent points.
> >
> > I believe GSoC is a very valuable program for the ASF and the projects
> > that participate, and I really hope the volunteers stepping up to
> > organize keep doing it.  I'll try to remember to thank you more often!
> >
> > Separately, it's great when we can also improve things, or at least show
> > some sort of progress towards helping our project's communities grow.
> > Given the rest of the organization that GSoC brings, and the fact that
> > our LDAP and other records are getting pretty easy to script against, it
> > would be great if some volunteer wanted to track people who became
> > committers from GSoC to see their contributions in the future.
> >
> > But just because no-one has stepped up to do the metrics doesn't mean we
> > should stop GSoC.  If people want to volunteer to do something that's
> > generally positive, great.  Suggestions for improvements are good;
> > getting in the way to slow progress because some additional goal hasn't
> > yet attracted a volunteer to do it is not as good.
>
> I don't think anyone has actively suggested we stop GSoC. But it would
> be good to see more cohesion in ComDev and some discussions on what we
> are doing, how it benefits our mission, and what the results are.
>
> Rich's original question was "does it benefit the ASF?". We don't seem
> to have bothered answering that question in a diligent matter over the
> past years, and I think we should do so. If GSoC is as valuable as the
> proponents say, then it should be easy to gather some more non-anecdotal
> information that says "yes, this has helped develop the community".
>
> I'd be super interested to learn what GSoC actually achieves, I have no
> idea if it's just a charitable coding-for-money scheme or if it actually
> helps grow our community in the long run. I also have no idea which
> aspects the projects find most useful, and I'd love to learn that.
>
> What I would be most interested in, however, is (as stated above) more
> cohesion in what ComDev does and how it is done. There should be at
> least some form of point of there being a PMC.
>
> With regards,
> Daniel.
>
> >
> > - Shane
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message