This site is an archive; learn more about 8 years of OpenHatch.

[Events] Planning a GNU Contributors event

Asheesh Laroia asheesh at asheesh.org
Wed Dec 7 20:40:31 UTC 2011


On Wed, 7 Dec 2011, Asheesh Laroia wrote:

> Hi John,
>
> I wanted to email with the notes from our conversation a couple of 
> months ago.

In terms of which project should "go first" for a new-contributors event, 
here's my thoughts:

* Emacs is a good one because many users know Emacs lisp already

* MediaGoblin and F-Droid are good because of the strong, active Python 
community here in Boston

I would suggest Emacs would be the easiest to attract people who are 
committed to GNU ideals and therefore likely to stick around. Just to set 
expectations properly, one thing I've seen relatively frequently is that 
there are people who hack on projects at sprints and never at other times. 
You're probably going to cultivate a few people who are like that. That's 
okay! They're great people to have as part of a community.

The most important things for having a high-quality sprint, I believe, for 
new contributors, are:

1. Well-tested documentation for how to get a dev environment going

2. Good-quality tasks for new contributors to work on, perhaps tailored to 
the particular interests of specific attendees if you know them well.

3. Availability of current contributors to the project to answer 
questions, plenty of which will come up.

4. Give people a link to the rest of the community so that when they 
leave, they can feel surrounded by activity.

5. Get their chagnes pushed/committed/merged/etc. during the sprint! Don't 
wait until afterward.

I think it'd be best to have that event before LibrePlanet. I imagine we 
might want to do this as a Saturday or Sunday daytime activity.

So -- how can we make sure to handle items 1-3 for a sprint on Emacs? 
That's the big question for me. Also, if there are others you want to loop 
into this conversation, we can CC: them or ask them to join the OpenHatch 
events list.

So John, let me know about items 1 2 and 3 (on-list is fine). If there's 
some stuff we should do off-list, like discussing dates or some sensitive 
details, we can do that too.

Depending on your needs, I can possibly help with (1) or (2). I'm more 
interested in checking others' work, since I'm not an Emacs expert ("just" 
a user!). So I would be extremely happy to put time into testing the dev 
environment documentation if we commit to running this event together, and 
to sit down in person with people who would be there and talk more about 
what I'm imagining.

P.S. The Subject line is a pun, intended to be in-line with standard GNU 
jokes. (-:

-- Asheesh.


More information about the Events mailing list