[group-organizers] Advice on starting a python UG
cbc at unc.edu
Fri Jun 8 03:24:39 CEST 2007
Christopher Arndt wrote:
> I wouldn't bother to plan too much in advance. If you have 3-4 people
> willing to meet, agree on a date and place and off you go. The rest will
> develop if the "vibes" are good.
Thanks, Jeff Hinrichs, for making the first post to this list. And
thanks for revitalizing Omaha Python.
I've been talking a lot to people wanting to form Python user groups in
the last year. My first advice is the "Shotgun Rules for BAD Meetings"
where BAD means "Bay Area Debian:"
It's the wisdom of these rules, and not the dogma. My group, TriZPUG,
adheres to them in spirit but not wholly in letter. For instance, we do
something not in the rules which I think is very important: fixed
meeting place and time. Also, we don't meet in restaurants or bars. We
meet in places where we can have presentations, and then go out to
restaurants and bars afterwards.
We have meeting *facilitators* whose job, and these are the *only* jobs
we have as a user group, is to secure the meeting room (with accessible
wireless and a laptop projector) and post meeting announcements to our
mailing list and website (and sometimes other places if they feel like
it) when it is their turn to host.
Now, this is specifically to say, it is *not* the job of a meeting
facilitator to give, or even find someone to give, a program. By the
shotgun rules, if someone wants to give a program, well, there's a
meeting every month. All they have to do is speak up on your mailing
list and say "I *am going to* give a program on subject X during next
month or month Y" and they are automatically "it." Asking permission is
not part of Python culture.
Also, just because one person is giving a program doesn't mean that's
the only person who can be giving a program at any given meeting. Two
programs, three programs, should be no problem. Don't worry about having
too many programs. That's a good problem to have.
In fact, the best meetings are when everybody who shows up stands up and
gives a five minute lightning talk about something cool they learned in
the last month. I mean, if you are using Python, then I know you've
learned something in the last month. Spend five minutes and tell us
about it. No matter how trivial it may seem to you, somebody else
doesn't know about it. User group meetings are show and tell at their heart.
Now, a lot of user groups or meeting facilitators I've seen for other
groups might come up the day before the meeting and say, well, no one
has volunteered to give a program yet, therefore I'm calling off the
meeting. This is the absolute worst thing you can do. Don't be a
gatekeeper. The best meetings TriZPUG have ever had have been meetings
with no planned program. If you get even just three Python programmers
with a pulse in the same room with a laptop, they will find something
interesting to do.
Never meet somewhere which isn't public. Don't meet at private companies
or businesses. Especially don't meet in places where the door is locked
and you have to be buzzed in, or which require ahead of time a list of
people coming for security to badge and check in. You keep the best
people away when this is your culture.
If at all possible, find a meeting facilitator, someone interested in
Python, who is staff or faculty (don't depend on students and I won't
explain why if you don't already know) at a public university and who
can provide a open meeting place in a university classroom or conference
room. At most public universities, any faculty or staff have plenty of
ability to schedule a meeting room with whomever they want for no other
purpose than they just want to. And wherever you meet, it should be free
from any fees for meeting there.
As soon as the meeting is "over," head to the nearest tavern with
everybody who doesn't want to go straight home. Because the absolute
best part of the meeting is the *after-meeting*. That's where the real
possibilities occur. Because of ideas and activity which started at
after-meetings, TriZPUG has hosted four (soon to be seven by the end of
this summer) week-long training camps and one eight-day international
conference in the last two and a half years.
Finally, and this is very important, resist all temptation to formalize
some kind of group structure and resist all persons with this tendency.
The point is to share information about Python. Everything else is a
useless diversion. A Python user group should not be modeled on a junior
high school student council, a Jaycees club, or a Moose Lodge. User
groups who take the structure approach spend most of their time and
energy arguing and debating over what to do, who *else* is going to do
it, and who didn't do what somebody else thought they were supposed to.
You need to protect yourself from this kind of tendency. Anything you
need structure for, the PSF already provides for user groups who
actually need it. If the PSF doesn't offer it, you probably don't need
it and are veering off into gatekeeper mode.
Remember this model:
Mutual support network of autonomous individuals.
Following that model will lift the most boats with the least amount of
How do you get people to come? I think Christopher Arndt already made
good points which are essentially, identify local subcultures of
interest and respectfully leverage their communications channels. Your
intuition to email GIS user groups is very good. This group at
University of Arkansas - Fayetteville (that's northwest Arkansas, no?)
does modeling software with Python and I bet they know other local
people using Python:
There's quite a bit of contact information for people in that behavioral
modeling group on the site. I wouldn't hesitate to contact individuals.
They could help with meeting places on campus, I bet.
Before you use community communications channels, start an email list
and a website. It would be good to use a content management system or
blog for you website which allows people to join the site as a member
and contribute content (like meeting postings and presentations). When
you contact people, you will need ongoing communications channels. Be a
Also, get that meeting time and place nailed down as early as possible
when contacting people, so you will have some plan of action you'd like
to invite the people whom you are contacting to do (come to a user group
meeting). Don't just meander with "Hey, would you like to start a user
group?," or "Who would like to start a user group?" Pick up that shotgun
and fire away. "Hey, there's a Python user group meeting in Room 222 of
Monty Hall on the campus of UArk at 7pm on Tuesday June 24. There's
parking behind the building after 5pm. I'm giving a talk on ctypes. You
should give a talk, too. We'll go out for beer and pizza afterwards
within walking distance. Join our mailing list at lists.nwarkpug.org for
further updates and to tell us what you'll be talking about at the
meeting. Invite your friends, too."
Have a sprint as soon as possible. It doesn't even have to have a topic.
It can just be a code jam for a few hours on a Saturday to work together
on whatever anybody is stuck on. Awesome things come of that.
One last parting shot: what about Meetup.com? Essentially, Meetup.com
creates gatekeepers and many other evilnesses too numerous to describe.
But Meetup.com has set up a shell Python meetup group for every
crossroads in the U.S. and many abroad. It would be foolish to ignore
Meetup.com as a resource, since they have these local Python meeting
honeypots already set up and they are usually the first thing anybody
googling finds when looking for a local Python user group. Just don't
use them for an email list or website for your user group. Use them as a
pointer to more egalitarian and less encumbered communications channels.
office: 332 Chapman Hall phone: (919) 962-4323
mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599
More information about the Group-Organizers