[group-organizers] Advice on starting a python UG

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

Excellent advice.

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.

Good luck!


Chris Calloway
office: 332 Chapman Hall   phone: (919) 962-4323
mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599

More information about the Group-Organizers mailing list