Talk:Mailing lists/Standardization

Proposal to make policy

Hi everyone,

After working on a documentation overhaul of mailman as part of the quarterly goal to upgrade the installation, I decided to dedicate a bit of time (with the help of others) to move an actual standardization policy. This is the draft we have come up with and would like to propose this to the community as a global policy. Improvements are welcome (though best discussed) and comments on the general idea and any implementation methods are welcome as well. Thanks, John F. Lewis (talk) 19:34, 25 September 2015 (UTC)

Inconsistency in examples.

In your examples of naming you have "wikidata-oversights, commons-oversighters." I presume they were intended to be the same, but don't know which was intended? Thryduulf (en.wikt,en.wp,commons) 19:49, 25 September 2015 (UTC)

They were! Thanks for pointing that out, fixed. John F. Lewis (talk) 19:49, 25 September 2015 (UTC)

Globally established groups

What do you mean by a "globally established group"? You use the example "arbcom-en", but that would imply an arbitration committee with jurisdiction on all English-language projects. The one I serve on is limited to the English Wikipedia only, and so "wikipedia-en-arbcom" would be expected based on the preceding logic? Thryduulf (en.wikt,en.wp,commons) 19:51, 25 September 2015 (UTC)

Globally established groups was intended to come across as a group or set of users (or functions) which exist globally (like stewards, global oversighter/checkuser lists, arbcom, ombudsmen, global-renames and so on). Wording is not the best and the idea here would be to come up a clearer more defining name I guess. Yes, Arbcom is a bit awkward but wikipedia-en-arbcom would be the best approach I guess rather than arbcom-en due to the single project focus. arbcom-enwiki may also be an alternative to wikipedia-en-arbcom, though a topic for discussion. John F. Lewis (talk) 19:55, 25 September 2015 (UTC)

future

If the aim is to apply this to future installs - fine. But I'm no fan of renaming lists, it mainly creates a mess in filters, people keep sending emails to the wrong address for a long time and it's a hassle. I don't see an immediate need to change names for existing lists. One practical question with regards to renaming, if you want to push it anyway, is whether the links to the archives that already exist will keep working. People point to discussions in the archives all the time, and if those links break... well, that would suck. Effeietsanders (talk) 09:46, 26 September 2015 (UTC)

This is indeed only to create consistency in future and make lists follow this if they want to be renamed (it has happened a bit recently and the process is there and easily do-able). Archive rebuilding is a poor topic to discuss. It's been practise for years for operations to modify mbox content and not rebuild it or other actions which have an impact of archive numbering, this does pile up as does unfortunately mean archives are re numbered significantly. Though all the practises have (and are) being actively discouraged especially with archive editing. John F. Lewis (talk) 11:37, 26 September 2015 (UTC)

Sorry User:John F. Lewis, I'm not sure I understand. Will the link keep working or not? If I read below, it seems not - but it also seems that you will not require any renaming anyway. Which is fine then, I guess. Effeietsanders (talk) 22:30, 5 October 2015 (UTC)

Discussion lists vs request lists

I feel that an important distinction is missing in this proposal: some lists are discussion lists while others are request lists.

By "discussion list", I typically mean lists which you join in order to participate in a group discussion. These are often open-subscription and accept posts from subscribers only, like wikimedia-l.

Others lists are "request lists", whereby typically membership is closed to a certain functionary group, and non-members email the mailing list to send a message to members of that group.

I can see it'll be useful for the former group (discussion lists) to retain the -l suffix, and the latter group shouldn't have a -l suffix. Deryck C. 16:25, 26 September 2015 (UTC)

There really is no distinction to be made. Public and private lists are discussion lists, though they have different intended targets. Your description actually matches what I mean. The request list element you're trying to get across I'll take arbcom-l as an example. It matches your description of a request list yet is actually an internal discussion list. All mailing list are, in theory and should be, discussion lists. The -l suffix will not be used at all as it is a very ugly legacy of when email lists were a part of @wikimedia.org, which is not the case now as they have their own dedicated domain handle now. John F. Lewis (talk) 22:37, 26 September 2015 (UTC)

Global listinfo

Many lists, particularly private lists, have removed themselves from the global listinfo page because of spam. I can tell you based on my experience of moderating a slew of private lists that spam was significantly reduced when they were removed from the listinfo page. Many private lists also do not accept emails from outside of their circulation. I do not see a benefit in requiring that private lists be included there. Risker (talk) 04:30, 29 September 2015 (UTC)

Naming

Some mailing lists, checkuser-l and stewards-l do contain an "-l" suffix as a legacy. I'd like that at least on these old, active and widely used mailing lists we could keep the current name. We're all already familiar with their names and it makes no harm keeping their names as they are. Thanks. —MarcoAurelio 07:37, 29 September 2015 (UTC)

Sharing the opinion of Effeietsanders above. Regards, —MarcoAurelio 07:38, 29 September 2015 (UTC)

please see my comment above in that section. These are only to apply for new lists or ones being renamed on request. Old lists which aren't asking to be renamed shall stay as they are unless in future some technical reason emerges (unlikely). John F. Lewis (talk) 14:10, 29 September 2015 (UTC)

Thanks! —MarcoAurelio 17:46, 29 September 2015 (UTC)