On Tue, 2006-03-14 at 20:23 +0000, robert burrell donkin wrote: > On Tue, 2006-03-07 at 19:13 +0000, Stephen Colebourne wrote: > > Reposted (edited) from original commons proposal. > > Currently this proposal has general, though not unanimous, support. > > A vote thread may follow this thread if the mood remains positive. > > i'm a little unsure whether this will turn out for better or worse but > if people out there have energy, i'm willing to give it a go. time's > probably right for a little innovation and experimentation. > > i like the idea of tagging emails better: a single list with cool server > side filtering and metrics. we don't have the technology for this yet so > i'm willing to see the mailing lists split so long as people would be > willing to consider coming back if it every arrives...
I was just considering proposing exactly this! The issues about groupings, subprojects, etc. are completely irrelevant it seems to me. A community is the set of people subscribed to emails about a particular project, no more and no less. Unfortunately the way email lists are currently run at apache forces a strict hierarchy onto community structure, and forces a choice between coarse-grained and fine-grained style communities (eg one commons list vs one-per-project). PMCs are structured hierarchically, and that is reasonable, but communities don't need to be this way. The perfect system, to me, would be a website that allows a user to register a username/email-address; the process would confirm that the user's email address is valid. A set of checkboxes would allow a user to "subscribe" to various lists, or to virtual groupings such as "jakarta commons" which would implicitly subscribe to the list for every project that is tagged as being a jakarta-commons project. Of course this implies fine-grained email lists (ie one for each project); the problems of partitioning the subscriber base too much is avoided by the existence of the groupings. This system would allow overlapping groups to occur; for example commons-digester can be filed under both "commons" and "xml" virtual groups; someone subscribing to *either* group would receive digester-related emails. It also allows projects to move from one PMC to another without destroying the existing community (which *is* the set of people receiving emails). Groups also allow new projects to be created and added to the group; all people subscribed to the group would then automatically get emails related to that new project. Any list which has less than 3 subscribers would automatically forward its emails to the PMC list (or similar) for purposes of oversight. Any person subscribed to 3 or more projects associated with "commons" would automatically be subscribed to the whole commons group (or maybe just sent a weekly nag email recommending they do so). That hopefully allows casual commons developers to get just postings for one or two projects, without destroying the useful commons-wide community that exists now. Having a single point for managing subscriptions would also help greatly with something that regularly frustrates me: suspending subscription when I'm away on holiday. Currently, I need to unsubscribe to half-a-dozen lists then resubscribe on return. This sort of functionality probably already exists in one of the open-source mailing list management packages; it isn't anything radical as far as I can see. Cheers, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
