[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