[Mailman-Users] Alternatives for Yahoo Groups like Web Features

[Brad Knowles]

On Aug 7, 2012, at 11:16 AM, Jason Glazer <jglazer at gard.com> wrote:

> a) a way for designated members to upload files that others can download

A wiki could solve this problem.

> b) a way for designated members to add events to a shared calendar that anyone can see

Hmm.  No good shared group solutions in this space that I know of.  Google lets you have a group calendar that can be shared read-only, but you want to carefully control who is allowed to make changes to it.

> c) a way to conduct simple polls to gauge interest in topics

SurveyMonkey and PollDaddy are two solutions in this space.  I know some of the SurveyMonkey folks in SF -- they're good people.

> d) a way for members to add links to a page to build up a library of good links
> 
> e) a way to create a FAQ page
> 
> f) perhaps a wiki-like way to create and edit pages in a freeform basis

I think a wiki would be at least a good way to solve all these problems, if not the best way.

> What I am looking for are suggestions on what has worked well together with an existing mailing list. What have others used and found easy to administer and easy for list members to use.

The problem is that you're not going to find a unified solution to all these problems.  You can run separate services for different parts of the problem space, as we do for list.org -- the mailing lists are hosted at python.org (they came first), the main website is hosted on private servers that few people have access to and mirrored by the fine folks at gnu.org (among others), the wiki is hosted by Atlassian on behalf of list.org, and there are various bug tracking systems that have been tried out over the years.

But those are still multiple separate services, located at various different locations, and no one person that I know of (other than maybe Barry) has had a hand in setting each of them up or is continuing to be involved in their ongoing maintenance.

> Any suggestions?

The biggest suggestion I'd make is to select tools based primarily on how useful they will be today and how easy they will be to administer on an ongoing basis once they are initially configured.

Don't waste time "overbuying" for future capacity and features that you may not ever need, especially since that may make it less likely that the system in question actually gets launched in the first place -- witness the various bug tracking systems that we've tried to use over the years.

--
Brad Knowles <brad at shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>