Talk:Development process improvement/Communications recommendations

Previous page history was archived for backup purposes at Talk:Development process improvement/Communications recommendations/LQT Archive 1 on 2015-07-10.

Guillaume, regarding this edit -- sorry for disrupting the intent of your words. I am genuinely a bit hazy on what you mean here, though now I see you intend more generally "users of Wikimedia stuff." If I may suggest, it seems like there are two ways to go here -- either simply and generically say "stakeholder" (which I think is probably best for this intro section), or spell out in more explicit detail exactly who you mean. I stumbled on the current text, and it seems like others might as well. (Overall, I think it's a very helpful document, and am very glad you've taken the time to create it.)

I'm not terribly enthusiastic about renaming mailing lists, only because it's difficult to rename a list and to preserve URLs to the old mailing list content. Since we have so many old conversations that we often reference, we should probably have a pretty high bar for renaming an existing mailing list. For example, I don't believe changing "mediawiki-l" to "mediawiki-users" would clear that bar.

I disagree that "we have so many old conversations that we often reference". A link search for http://lists.wikimedia.org/pipermail/ on mediawiki.org return many results, but almost all of them are links to release announcements. They appear on many pages only because they're included into "news" templates. They can hardly be considered useful reference materials (which should reside on the wiki anyway).

In any case, I had done a little bit of research about list renaming before writing these recommendations, and that's why I recommended very few of them. Renaming Mediawiki-api to Mediawiki-api-users and mediawiki-l to mediawiki-users is obviously optional (notice the "perhaps" and the question mark respectively in the table :). That said, renaming "mediawiki-cvs" to "mediawiki-commits" would make sense, and shouldn't be too much of an issue. It will teach us not to use tool-specific names in the future :) FYI there are about a hundred subscribers.

To be honest, I'm more interested in retiring or merging unused lists, and splitting lists that mix different topics.

A general purpose search is more appropriate to my point. Regardless of where these discussions belong, many are where they are, and it's silly to break links to them if we don't have to. Mailing lists are actually some of the best ad hoc reference materials on the web, and we shouldn't diminish their role. Obviously, getting material onto wikis is better, but that isn't always realistic, and often the email conversation ends up being clearer to understand than documentation written to purpose.

Retiring lists generally seems fine, so long as we keep the archives around.

Obviously, getting material onto wikis is better, but that isn't always realistic, and often the email conversation ends up being clearer to understand than documentation written to purpose.

We're obviously reaching a difference of opinion here.

So do you think it's realistic to get every insight from every piece of email onto a wiki in a uniformly cleaner and understandable form than it originally appeared on the mailing list?

What I think is that there are more important things to spend time and energy on.

I chatted with RobLa about this last week and uncritically agreed with him. Perhaps I was in an overly agreeable mood that day. :)

Thinking about things a bit more,I'm a fan of putting more things into the docs and having less adhocumentation on the mailing lists.

Every time that someone can answer a question by pointing to a URL, a few good things happen:

• the contents at the URL can be updated over time. Mailing content goes stale fast and can lead people very far astray.
• more link love goes to the right URL in the docs, not to the mailing list archives.
• the list readers learn about the docs and how to read them.
• the listies get feedback when the docs suck.

All these things make it so that there are way better returns on updating content.

Lists are still really important and something discussions in a list can't be captured easily in documentation. However, most of those discussion aren't really documentation fare.

You touch on Bugzilla in here, but only as a bug tracking tool. For better or worse, it ends up being an ad hoc mailing list creation mechanism (i.e. once an issue is posted, anyone can sign up to be on the cc line, and discussions often ensue). It's important to acknowledge that role regardless of whether we think it's appropriate, so that we can open a discussion about whether it's appropriate. If we don't think that's a good use for Bugzilla, we probably need to make sure we have a suitable replacement before we recommend not using it for that. I don't have a strong opinion on the appropriateness of it, but I know a lot of people don't particularly care for that usage, and I know that others find Bugzilla intimidating.

Hi Guillaume - sorry for not responding sooner. I've got lots of comments, but rather than save them up, I'll post them as separate comments. In general I think this is a wonderful assessment. I'll probably be bold about editing this doc after having some discussion here on some of the points first.

BTW, I'm sitting six feet away from Guillaume right now, and I'm commenting here. Look at us being all transparent ;-) /me pats self on back

Guillaume, you seem to suggest it for every list to be renamed/splitted. This is an ugly leftoff from times when there was no separate domain for lists and this suffix was useful for differentiation between lists and normal email addresses. Now it's not needed and is actually not used by new lists.

Hi Max. I know it's not needed any more :) I think it has become a habit for many Wikimedians, and that's probably the reason why even some recently created lists have the -l suffix. It's really a detail and I'm fine either way. Feel free to edit the page (not only for that, by the way).