MESSAGE
| DATE | 2009-08-04 |
| FROM | Contrarian
|
| SUBJECT | Subject: [NYLXS - HANGOUT] closest I've found to a conference HOW-TO
|
But it's a LUG HOW-To
Finally found this with "Rick Moen" without "conference"
Recipe for a Successful Linux User Group
http://linuxmafia.com/faq/Linux_PR/newlug.html
Recipe for a Successful Linux User Group
by Rick Moen
Last revised: 2008-11-13
Having seen (and run) quite a few Linux user groups (LUGs), and
observed some thrive and others die, I can hazard some firm
recommendations. If you're thinking of starting a LUG, or are running
one now, please ponder these lessons, drawn from other LUGs'
experience. In fact, please consider reviewing this list from time to
time, as a kind of checklist.
1. You need a Web page.
I can't stress this enough. The Internet is crucial to Linux: It made
Linux possible, and is where everything happens. If your group isn't
on the Net, it might as well not exist.
By "the Net", I mean not just Web pages, which are its most-visible
service, but also mailing lists, Usenet newsgroups, and ftp file
archives, among other things. It's your source for software, the forge
where open-source tools are designed and crafted, your method of
publication, your social club, and your research library.
Each major function of your group should have a Web page: If you start
doing InstallFests, create an InstallFest page.
2. Your Web page needs a reasonable URL.
The usual http://www.some-isp.com/~username/lugname/ URL isn't good
enough: You want people who know no more than the group's name to find
you easily. For that, http://www.lugname.org/ is ideal in the USA --
and you can use similar formulas elsewhere, such as
http://www.lugname.org.au/ . Consider choosing a group name whose
Internet domain isn't taken (check at
http://www.internic.net/whois.html, for com/org/net domains), and then
paying to register that domain and have an ISP virtual-host it. It's
not that expensive.
Given that this is the Linux world, the odds are that one or more of
your core volunteers owns a co-located Internet host, and will be
willing to host your pages and domain for free.
The odds are that your Web page will start out somewhere less
desirable, such as a subdirectory of someone's home page, or a free
hosting service such as Geocities -- but you should aim towards having
your own domain, in the longer term.
Remember that the Net is world-wide: If the best/cheapest hosting is
at (say) a friendly LUG site on another continent, take it.
3. You need a regular meeting location.
Changing meeting locations risks losing attendees like mad. Why?
Because some will come to the prior meeting location, instead, get
discouraged, and maybe even conclude that your group has folded -- and
also because finding out how to get there, where to park, whether the
neighbourhood's OK to walk in, etc., is a strain on people, each time
you move.
The location doesn't have to be impressive: I've seen a college
cafeteria suffice for one group, and a small downstairs room in
someone's house do well for another. It just has to be reliably
usable.
4. You need a regular meeting time.
"Regular" usually means following an easily-remembered-and-used
formula, suitable for people's calendars, pocket planners, and
PalmPilots -- such as 4th Thursday. Don't get fancy with things like
"every other Thursday": Make it so anyone with a calendar can easily
figure out when the next meeting will be.
5. You need to avoid meeting-time conflicts.
Check out the schedules for nearby technical events: Linux user
groups, Perl groups, and whatever else your target audience is likely
to want to also attend. Don't pick recurring dates that those other
groups are already using. Hint: 1st & 2nd Tuesdays, Wednesdays, and
Thursdays are over-popular meeting days: Their attraction is that
they're easy to remember -- and mid-week days are generally good for
people. But, in my immediate vicinity (for example), there are four
competing groups sharing first Tuesdays.
6. You need to make sure that meetings happen as advertised, without
fail.
One LUG in my area fell apart largely because the president set an
aggressive meeting schedule, and then failed to show up to unlock the
meeting room. Would-be attendees then looked up the next meeting date
on the Web, showed up, found a locked door, and (soon) give up on the
group entirely. So, if possible, have multiple people arrange to show
up early. Also, post signs/flyers near the meeting site.
If you need to cancel or reschedule an event that you've already been
advertising as "upcoming", don't simply remove the original listing on
your Web pages: Continue to list it, prominently marked as
cancelled/rescheduled.
7. You need a core of several Linux enthusiasts.
LUGs have succeeded wonderfully on the strength of ongoing efforts
from as few as four energetic and inquisitive people. That's really
all you need, but one or two are not enough. E-mail is terrific for
coordination.
Your core enthusiasts don't need any Linux knowledge initially, but
must be "self-starters", and must have Internet access and know how to
use it well.
8. Your core volunteers need out-of-band methods of communication.
By that, I mean outside your user group's regular electronic means of
communication. One college LUG operated all e-mail mailboxes used by
its officers through the LUG's Web server machine, which then went
down at the beginning of summer recess. It thus proved the proverbial
"single point of failure" for group communications. Most officers
change residences at the academic year's end, and there weren't even
summer LUG meetings scheduled for regular dates, so the LUG nearly
collapsed because its principals lacked any means of getting back in
contact with one another.
Having circulated a list of stable non-LUG e-mail addresses, telephone
numbers, and/or postal addresses would have averted this
near-disaster.
9. You need to get on the main lists of LUGs, and keep your entries
accurate.
* http://lugww.counter.li.org/
* http://nlug.org/webring/
* http://www.redhat.com/opensourcenow/
* http://www.linux.org/groups/
* http://dmoz.org/Computers/Software/Operating_Systems/Linux/User_Gr
oups/
* http://dir.yahoo.com/Computers_and_Internet/Software/
Operating_Systems/Unix/Linux/User_Groups/
Assign someone in your group to re-check your LUG list entries
periodically, say, every quarter. You'll be amazed at how inaccurate
they become over time. Keep a list of all the places where you have
such entries, and also a "publicity" list (of places you send notices
of upcoming events). Sometimes, it helps to print these out and use
them literally as checklists.
An inaccurate LUG-list entry is often much worse than none at all:
When it directs prospective members to an obsolete URL, or tells them
the wrong meeting date, that actively hurts your membership effort.
So, before submitting an entry to any LUG list, do some spot checks on
the existing entries' general level of accuracy. Widespread inaccuracy
(e.g., dead links, wrong information on meeting dates and places) may
indicate a hidden gotcha: Some lists are so badly maintained that
their staffers ignore corrections you send in. For example:
* http://www.currents.net/resources/usergroups/usanc.html
That list is a trap for the unwary LUG leader, in accepting additions
but appearing to ignore correction/update notices: Once your entry
becomes out of date, it stays that way.
(Some will have noticed the dropping of linux.com's longtime LUG list:
The site's owner, VA Software Corporation, decided around September
2002 to blow away seemingly all pages not aimed solely at the Fortune
500. Oh well. No big loss.)
(More sadly, SSC, Inc. summarily deleted the GLUE = Groups of Linux
Users Everywhere directory some time in 2005 and replaced it with a
Web redirect to www.linuxjournal.com. That extensive LUG database and
information exchange will be sorely missed, and it's a shame SSC
offered nobody in the Linux community any opportunity to adopt the
site.)
10. You must have login access to maintain your Web pages, as needed.
An unchanging page that someone else created for you isn't good
enough: You need to be able to fix/edit/enlarge your site on short
notice. Typically, this requires login access via ssh [1] (or telnet,
if necessary) to the hosting Web server's command shell.
A number of Linux groups attempt to get by with a static page on some
site to which they themselves lack maintenance access -- for example,
on a parent group's existing Web site. The convenience isn't worth the
disadvantages: Don't go that route.
11. Design your Web page to be forgiving of deferred maintenance.
Much as we'd like our LUGs' "upcoming events" and other time-sensitive
information to be always current, it isn't going to happen: Sometimes,
you don't re-check and update them for a week or two. Therefore,
always list several months' upcoming events. (You know when they'll be
because you have a meeting-date formula, right?) That way, when you're
unavailable for Web-page maintenance for two months running, the Web
page will still include current meeting information.
Somehow, my local LUGs' webmasters seem resistant to that simple idea,
with the result that most list only one upcoming meeting at a time,
which, for three quarters of the month, because of the inevitable
deferred maintenance, ends up being last month's date.
The whole point of listing specific upcoming meeting dates is to make
it unnecessary for casual visitors to work out when the next (say) 2nd
Tuesday will be, by doing it for them. But that effort is wasted when
the only meetings shown are already past: It makes new LUG members
that much less likely, and additionally may lead some to think your
LUG is now defunct.
12. Always include the day of the week, when you cite event dates.
Always check that day of the week, first, using gcal [2] (or cal).
gcal is your friend.
Why always include the day of the week, on event listings? Because
that gives viewers their best shot at remembering your event, how many
days away it is, and how it fits into their schedules.
Additionally, the fact that you've furnished the correct day of the
week for each date reassures visitors that you haven't messed up and
listed the wrong date (which happens depressingly often) -- in effect,
a cross-check. Conversely, take care not to list a meeting's date
correctly, but with the day wrong. That conveys the (probably
accurate) impression that your event calendar can't be trusted.
It doesn't hurt to print out the current year's "gcal" listings, for
reference whenever you're doing calendar work. Mark significant
holidays for your country on it: You can get them from
http://www.religioustolerance.org/main_day1.htm,
http://www.web-holidays.com/,
http://www.mozilla.org/projects/calendar/holidays.html,
http://www.apple.com/downloads/macosx/calendars/, etc.
13. Place time-sensitive and key information prominently near the top
of your main Web page.
Don't banish all meeting information to your events page, or tuck it
into an unobtrusive text box for aesthetic reasons: Ensure that the
most prominent items on your site are the ones viewers need most.
Consider using "STRONG" or "EM" HTML tags on particularly important
items, such as your date formula (e.g., "second Tuesdays at 7 PM").
Displaying time-sensitive information prominently is useful not only
because that tends to be what viewers seek most often, but also
because such text calls your attention to itself, when it needs
updating. Think of this as comparable to putting perishables near the
front of your refrigerator, date-stamp outwards.
14. Include maps and directions to your events.
Some prospective members will be comfortable with maps, others with
directions; you'll want to help both. Maps can be generated (for the
USA, at least) on Yahoo Maps, Google Maps, MapQuest, or MSN Maps
(formerly MapBlast). Have them as links for each listed event
location. If there's a trick to parking nearby, describe it. If public
transit is available, give details.
Remember: Directions and maps are (particularly) for people who aren't
yet members, not for your existing "in-crowd". The Web page for one
LUG near me used to omit maps and directions, giving only the meeting
date/time and the name of the building where it met. Don't fall into
this common trap of making your pages useful only for existing LUG
members.
One of the themes of this essay, in fact, is: Try at intervals to look
over your LUG's public information as if you were an interested
newcomer. Does your public information (e.g., your Web pages) tell
prospective members what they need to know? Is the most important and
most time-sensitive information also the most prominent? If not, you
need to redesign it.
15. Emphasise on your main page that your meeting will be free of
charge and open to the public (if it is).
Believe it or not, some prospective members will assume your group
costs money, unless you say otherwise. This is especially true of
people accustomed to traditional user groups, which generally must
charge dues to finance their dead-tree-media newsletters and other
money-intensive operations. (See addendum #1.)
Conversely, if there will be an attendance fee (e.g., to pay for
dinner), say so prominently, with the other event details.
16. You'll want to include an RSVP "mailto" hyperlink, on some events.
Set up an e-mail alias of "rsvp-at-groupname.com" pointing to the real
mailbox of one or more volunteer, and include it as a link on event
listings when you need an advance head-count (e.g., at restaurants).
Other aliases you'll want -- if you operate your own Web server -- may
include "webmaster", "postmaster", "president", "webteam", and "help".
If you use such aliases consistently for roles people fill, you'll be
better equipped to handle smoothly the inevitable turnover in
volunteers, over time.
17. Use referral pages.
Over time, you'll find it desirable to reorganise your Web documents,
rename pages or directories, or move the whole site (or part of it) to
a different Web server. That's inevitable -- but don't forget that
other Linux groups, user group lists, search engines, and assorted
individuals will have already created links to your old URLs, without
telling you they've done so. Thus, if you just move/rename your Web
documents, you will break one means by which interested parties are
accustomed to finding you.
The cure is to leave a "referral page" at the URL where the document
used to be, guiding the user to its new location. Get in the habit of
doing this whenever you would otherwise leave nothing where there used
to be a page: It's better than their getting a 404 error.
Here's an example:
New location for FOO Home Page
The FOO home page has moved! The new location is HREF="http://www.newlocation.com/">http://www.newlocation.com/
2008-11-13 note: A correspondent wants me to replace the above with a
recommendation of doing httpd status code 301 (permanently moved page)
redirects inside the Web server configuration file. This is indeed
ideal -- for those who have access to reconfigure and then restart the
relevant Web server, and who also have mastered configuration of that
particular software. (Naturally, "permanent redirect" details differ
between Web server packages.) The problem with the above-described
META refresh technique is that spammers' pages use it to try to trick
search engines, and so the engines discount the "page rank" (etc.)
value of such links.
Other aspects of site configuration can complicate implementation of a
301 redirect, such as whether the httpd maps multiple domains to the
same IP. Anyway, if interested in this sort of webmaster neepery, you
know how to search for it. (If tempted to use Apache httpd's
"mod_rewrite" code as opposed to "Redirect permanent" or "Redirect
301" directives for such a project, best of luck to you.)
18. Make sure every page has a revision date and maintainer link.
It's traditional to put some variation on "Send feedback to [link]" or
"Copyright (C) 2000 by [link]", or "Webmaster: [link]" where "[link]"
is the maintainer's name with a "mailto" hyperlink. And there's a good
reason for this tradition: It ensures that "feedback" comments -- from
sharp-eyed readers who catch errors, omissions, and ambiguities in
your public information -- will reach the right person. Make it easy
for the public to help you, and some of them will.
Putting a date stamp at the bottom of each page, whenever you update
it, reassures visitors that the site really is current. You may know
that it's a living site with current data, but newcomers won't. Dead
sites with obsolete data are far too common on the Web, and the date
stamp marks your page as freshly edited. (Equally, it reminds you of
when you last overhauled the site.)
Need I mention that the worst-maintained LUG sites in my area lack
revision dates and maintainer links? It's true.
19. Check all links, at intervals.
Probably your pages will contain numerous links to external sites, as
well as to other parts of the same site. The remote sites can and do
move around (or disappear) without your having heard, and local links
can and will break because of your own imperfect maintenance.
There's a quick and easy way to catch all such breakage: Open your Web
browser and clear its cache, which makes all links appear as unread.
Now, visit each link in turn. If you do this at intervals (e.g., every
six months), you'll at least find any broken links, and maybe other
people's referral pages for remote pages that have moved.
It's possible (but a non-trivial task) to find all sites that link to
your pages, by analysing your Web server's log files. That knowledge
will prove useful when, for example, your Web site moves or gets
substantially reorganised. (You can then advise the other webmasters.)
If you're feeling ambitious, try to find them. Search engines are
useful for that task: Google, Infoseek, Altavista, and others. (Don't
forget dejanews.com, for searching Usenet posts.)
One tactic that doesn't work: putting a note to webmasters on your
site, asking them to let you know of links to it. I had such a request
on my Bay Area Linux Events page (http://linuxmafia.com/bale/) for
seven years, with zero responses.
20. You may want to consider establishing a LUG mailing list.
Any reasonable Linux host (machine) with a constant Internet
connection can run mailing-list software. GNU Mailman
(http://www.list.org/), for example, is easy to set up and administer,
and comes with automatic Web-archiving for your mailing list. Many
groups find it useful to have both a main discussion list and a
low-volume announcement-only list.
Do not announce your upcoming meetings only to your mailing lists: By
definition, those will reach only existing members. The whole point of
having a public presence (e.g., Web pages) is to both serve existing
members and attract new ones.
Some commercial services let you set up "free" mailing lists on their
servers, where their gain lies in revenues from mandatory ads
auto-appended to all posts, plus of course the ability to sell your
subscription list to other advertisers. Beware that you may find
yourself not the "owner" of your own list, in the event of a dispute
over its management.
Some groups have founded Web-based discussion forums, instead of
e-mail mailing lists, either on their own servers or on commercial
services. I have yet to see one that wasn't stagnant and inbred. The
advantage of e-mail mailing lists is that e-mail is universal and
convenient for people, generally.
If you do run LUG mailing lists, someone will have to function as list
"owner", taking care of administrative requests and enforcing list
policy. The latter category will include dealing with job recruiters:
Many LUG lists have been overwhelmed with job ads from professional
recruiters, sometimes posted multiple times a day. A policy that has
worked well at one LUG is to require that all job ads be submitted to
a club officer, who then posts it with a subject header starting with
the string "JOBOFFER:" That way, the jobs postings' volume can be
controlled, and people not wanting to see them can filter on subject
headers.
21. You don't need to be in the Internet Service Provider business.
Leave the ISP business to the professionals. You won't be able to beat
their prices, so don't try. When the moochers in your crowd ask for
dial-in lines and shell accounts on the group's Web server, say "No."
22. Don't go into any other business, either.
I hear of LUGs being suckered into the strangest, most cockamamie
business schemes. Don't: Don't try to be a Web design firm, a
technical support firm, a network design consulting firm, or a LAN
cabling contractor. Or any other business. Not even if you're told
it's for a wonderful charitable cause.
Along the same lines, remember that you are not a convenience for job
recruiters: If allowed, they will spam your mailing lists and abuse
every possible means of communication with your members. Nor are you a
source of computers for the underprivileged, a repair service for
random people's broken PCs, or a help desk for non-Linux operating
systems and applications. Believe it or not, you will be pestered by
all of the above sorts of strangers, on the "nothing ventured, nothing
gained" theory.
23. Walk the walk.
It's painfully grotesque to see so-called Linux user groups mailing
out announcements using MS-Outlook, Eudora, or Netscape Messenger for
MS-Windows (or MacOS), or other proprietary mailers for legacy
operating systems -- and visibly maintaining their Web sites using MS
Front Page, Adobe Page Mill, or other junkware -- and hosting their
LUG mailing lists on Yahoo Groups (formerly eGroups and Onelist,
formerly MakeList) or Google Groups. Fortunately, these LUGs are in
the minority, but they convey the message of Linux being suitable in
neither desktop nor server roles.
If you are going to promote and explore Linux, you need to use it. If
you don't know what good, open-source tools for Linux exist to create
and manage Web sites (such as Bluefish, Screem, Mozilla Composer,
Amaya, Quanta Plus, and PHP), then ask around. Ditto for mail user
agents: Ask around, and you'll hear about excellent native-Linux
mailers such as Mutt, Mozilla Thunderbird, Sylpheed, KMail, Mahogany,
Balsa, Aethera, Evolution, Pronto, and Spruce. Ditto for mailing list
hosting: It's just unbelievably feeble and lame to have Yahoo Groups,
Google Groups, Topica, or some other "free" commercial service run
your mailing list when GNU Mailman comes already set up and working on
major Linux distributions, complete with automatic Web archiving and
Web-based administration -- plus you can even add to it mnoGoSearch as
an archive search engine, if you wish.
Don't volunteer to look like losers in public: As the saying goes, a
LUG needs to "eat its own dog food".
Addendum #1: A note about parent groups.
Many a LUG has gotten started as a sub-group of a more-established
parent, usually a general-purpose computer user group. For example,
SVLUG (http://www.svlug.org/), one of the world's largest LUGs, when
founded and for many years thereafter, was technically a SIG (Special
Interest Group) of the Silicon Valley Computer Society (SVCS).
The advantage to such an arrangement is that you can gain insurance
coverage, incorporation, and acknowledged non-profit tax status,
without having to handle the paperwork and expense of those efforts,
yourself. Depending on the people involved, the relationship can also
create genuine symbiosis (such as SVLUG having provided free Internet
services for SVCS).
There are also offsetting disadvantages: Established PC user groups
are often in decline, and tend to be run by people devoted to legacy
proprietary OSes who have no understanding of Linux or open-source
software. The potential for culture clash is a serious one, and the
odds are that your LUG members will have little interest in the parent
group's other functions.
Old-line PC user groups tend to have annual dues of US $40 and up, for
all members, and often charge admission for their monthly meetings.
They adopt this model in order to finance their paper-published
newsletters, (sometimes) to rent meeting space, and to pay sundry
administrative costs such as telephone and corporate-filings fees.
By contrast, a LUG can operate with expenses approaching zero: Its
publications can be Web-based. Notices can be sent via e-mail instead
of on flyers. Meeting space can usually be gotten for free at ISPs,
colleges, pizza parlours, brewpubs, coffeehouses, computer-training
firms, Linux-oriented companies, or other friendly institutions, and
can therefore be free of charge to the public. Having thus arranged to
have roughly zero revenues as well as expenses, there is little need
for tax-exempt status or incorporation. About the only thing you
forego without incorporation is insurance and liability-protection,
which shouldn't be a problem for modestly careful people.
So, the advantages of having a parent group are somewhat smaller than
would appear at first glance. You may find the parent group trying to
dictate your sub-group's policies, including the content and location
of its Web pages, and unhappy with your members who disregard the
parent group and fail to pay its membership dues. This has led some
Linux SIGs to split off from their parents as independent LUGs. Others
quickly become the tail that wags the dog, as with SVLUG and SVCS.
Some groups achieve other long-term arrangements, with varying degrees
of happiness on both sides.
Be aware of the issues and possible outcomes, in any event.
Addendum #2: LUG checklist.
The following checklist may be useful for your group, once
established.
1. Web page:
a. Meetings:
[ ] Current meeting info? Is it prominent?
[ ] Day of the week? Beginning time? Ending time?
[ ] Double-checked day/date matches against a calendar?
(E.g., is the "Friday, March 28" you listed an error, because the 28th
is a Thursday?)
[ ] Location?
[ ] Map?
[ ] Directions (car, public transit)? Parking tips?
[ ] Information on the next several meetings?
[ ] RSVP mailto link on meetings where this is needed?
[ ] Note that meetings are free and open to the public (if they are)?
[ ] If there's a special fee, is it disclosed next to the event
listing?
[ ] If location / time / date formula has changed recently, is this
noted prominently?
[ ] Have you checked for event conflicts with other nearby groups, or
with holidays?
b. General:
[ ] Includes event date-formulas (e.g., 4th Tuesdays)? Prominently?
[ ] Maintainer mailto link?
[ ] Last-revised date?
c. Periodically (maybe every quarter):
[ ] Checked all links on your site for dead links?
[ ] Checked your Web server's logs for pages requested but not found?
(You'll want to put a referral page at that URL.)
[ ] Read all your Web content attentively for outdated content?
2. Other, periodical:
[ ] Reviewed/updated all LUG lists that have entries concerning your
group?
[ ] Reviewed all sites that link to yours? Advised their webmasters of
needed corrections?
Addendum #3: Additional materials.
* You will certainly want to also read my Linux User Group HOWTO.
* Paul L. Rogers's Linux Advocacy HOWTO makes a good
companion-piece.
* Don Marti's Linuxmanship essay should be required reading for all
Linux activists.
* Eric S. Raymond's Conventions at Lightspeed addresses the running
of larger events by hacker-types.
* Kenneth R. Kinder's Linux Myth Dispeller is a bit outdated, but
still good.
* The redoubtable Christopher B. Browne has similar pages.
[1] ssh is a protocol for encrypted remote login (and inter-system
file transfer), protecting both your login authentication and the
subsequent session data against third-party eavesdropping. Despite
needing supporting software at both ends (server and client), it is
rapidly replacing telnet, because the latter is horribly insecure and
a leading means of account theft and system break-in. The best-known
implementation is also named ssh. Client software is available for
every consumer OS: See my list at http://linuxmafia.com/ssh/.
[2] gcal, the GNU calendar program, is a simple perpetual calendar
utility included on typical Linux systems. Typing "gcal" shows the
current month, while "gcal 2000" shows the twelve months of that year.
On some systems, it will be named "cal".
_________________________________________________________________
Copyright (C) 2000-2008 by Rick Moen, rick-at-linuxmafia.com.
Verbatim copying, distribution, and display of this entire article are
permitted in any medium, provided this notice is preserved.
Alternatively, you may create derivative works of any sort for any
purpose, provided your versions contain no attribution to me, and that
you assert your own authorship (and not mine) in every practical
medium.
|
|
