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" <humbed...@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-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
