[Events] Planning a GNU Contributors event

[John Sullivan]

Hi Asheesh,

Asheesh Laroia <asheesh at asheesh.org> writes:

> 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.
>

I think Emacs is the best first choice also. 

> 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
>

It has this, and it's very simple since Emacs is its own dev
environment. It's easy to load and unload code being tested without
having to compile or re-run any sort of setup tools. I guess the main
instructions needed here would how to check out and build the current
code from bzr. Also how to use bzr :). (Although, there is also an
up-to-date git mirror).

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

We have http://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=emacs to draw from
for possible tasks, plus C-h C-t which shows a TODO list, and C-h C-p
which shows a problems list.

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

The #emacs channel on freenode is very active and friendly, and we know
several people who would make good in-person mentors/guiders as well.

One of the primary emacs maintainers, Chong Yidong, lives in CT and has
attended at least one LP conference in Boston. We could reach out to him
and see if he might be interested in attending, and/or being in the loop
for planning.

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

Sure -- besides the IRC channel, and the official emacs mailing lists
@gnu.org, there is emacswiki.org.

I guess sharing code on the wiki and helping to improve it could be
another rewarding and productive form of participation during the
sprint. The wiki would probably also be a fine place to document the
development set-up process for the sprint (in fact, I bet the
instructions we need are mostly already there).

There is also http://planet.emacsen.org -- if people wanted to blog
about their activity during the sprint, we could get them on the planet,
and then they could stay on it.

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

This might be more difficult, but the emacs maintainers do reply very
quickly to proposed patches, especially if they pertain to existing
reported bugs. So I'm hopeful here too. If we gave the maintainers a
heads-up, we could probably get a better response.

> 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.
>

Agreed. The dates for LP have been set as March 24th and 25th.

-john

-- 
John Sullivan | Executive Director, Free Software Foundation
GPG Key: 61A0963B | http://identi.ca/johnsu01 | http://fsf.org/blogs/RSS

Do you use free software? Donate to join the FSF and support freedom at
<http://www.fsf.org/register_form?referrer=8096>.