Talk:Technical communications/Fall 2012 consultation

Out of scope ideas
Bugzilla-specific suggestions:
 * Try to find a way to do more with 'assigned'. (unassign automatically)


 * Could you elaborate? Does this refer to cookie licking? What would be potential criteria to "unassign automatically"? --Malyacko (talk) 20:44, 5 December 2012 (UTC)


 * For WMF issues, perhaps add a state 'scheduled' + date


 * My current take on this (not perfect but a first step) is that this should be done together with setting up a bot that pastes information from Gerrit automatically into Bugzilla. For example, if the Gerrit commit message of a merged code change matches a regex thar defines a bug number like ((b)[ug]{0,2}\s * [id]{0,3}|id|fix|pr|#)[\s#=] * \[?([0-9]{1,6})\]? then there should be an automatic notification in Bugzilla saying "Gerrit change ID 12345 has been merged and mentions this bug report. It can take up to two weeks until the code change is available on one of the Mediawiki wiki sites, depending on the deployment schedule at https://www.mediawiki.org/wiki/MediaWiki_1.21/Roadmap ." --Malyacko (talk) 20:44, 5 December 2012 (UTC)


 * Make a stricter separation between WMF and non-WMF items in bugzilla.


 * What are "items" in this context? The "Wikimedia" product vs. the rest? Bugzilla "Target Milestones" like "Visual Editor" product using them for deployments, while "MediaWiki" product using them for tarballs? --Malyacko (talk) 20:44, 5 December 2012 (UTC)


 * I invite you to follow up directly with the editors who made those comments; I added the references for this exact purpose :) guillom 09:08, 6 December 2012 (UTC)

Human filter and conduit
Re "There needs to be a human filter and conduit between users and developers, to bubble up serious issues and good ideas with consensus" - obvious COI, but I'm heavily in favour of Platform hiring a me-like figure (who isn't me. I have my hands full with Product ;p). I'd argue it should be a two-way street, though: bringing up good ideas to devs, getting feedback on dev ideas from editors, and acting as a triage of sorts to work out what sort of thing requires consultation/notification. Okeyes (WMF) (talk) 21:29, 5 December 2012 (UTC)


 * I agree on the 2-way street; that's the whole purpose of this project :) Would you generalize this suggestion to all subdepartments in Engineering? i.e., you're the Community Liaison (CL) for the Product group: are you recommending that we hire a CL each for Ops, Features, Mobile, Platform and Language groups? guillom 14:45, 7 December 2012 (UTC)


 * Oliver is I believe actually CL just for the E2 (Editor Engagement) product area, and we occasionally steal him for other Product activities because he's all we have. :-( I think all work areas of WMF Engineering have the need for liaising with the community of people that depend on them, but that doesn't always mean a dedicated person for that work, and it in general doesn't align with the organisational structure of Engineering. For example, Oliver's team (E2) spans Product and Features; someone jointly between Platform and Operations might make a lot of sense as the issues that arise in live are generally from one of those two areas; I believe that the Language team already do excellent work talking to their stakeholder base. There's also the question of which users do we mean - editors of WMF projects? Readers too? Third party MediaWiki sysadmins and users? Volunteer MediaWiki developers? Etc. Jdforrester (WMF) (talk) 18:11, 7 December 2012 (UTC)

feedback on potential experiments & suitability for Jan 2013
Rob and I just looked over the current ideas for potential solutions. Thanks for synthesizing and thinking about these issues and possible solutions. We were looking at them with an eye towards what would make sense as potential next experiments for January 2013. So the feedback here is about that rather than overall workability.

Ideas that require developer or systems administration effort are going to be substantially harder to implement as the next experiment, and probably can't get WMF tech resources -- I think the exception is that I am willing to spend Andre Klapper's time in Bugzilla improvements. :-) And suggestions that were listed as "long-term" solutions are not really being considered as the next experiment, right?  That's what we presumed as we reviewed the list.

Suggestions that add community capacity to do tasks that Guillaume currently does are better, to us, than increasing the amount of one-way communication the WMF does.

Suggestions that involve translation need to take account of:
 * pages still need to be very easy to edit by people who don't know as much template magic
 * some pages (like Roadmap) are VERY fluid, changing week-to-week, and even week-old translations may be actually damaging

And Rob is especially interested in figuring out what success would look like for tech ambassadors, and in seeing whether there's an experiment we could run to increase the chances of success with volunteer product managers or volunteer tech ambassadors. And then if we fail on that, then we would figure out how it failed, and get info to use with the next thing.

Regarding specific ideas Guillaume already listed:


 * "Add a link to Special:Version to a list of recent changes / curated changelog with UI changes, API changes, etc." is done! Check out . Suggestions for polish would be good.


 * The Bugzilla/CentralAuth idea is unfortunately probably not suitable for the next experiment. It would require Ops help, which is in short supply in the near future.  It would be much better to do with OpenID support rather than invest in modifying CentralAuth, but OpenID work is not going to happen in time and possibly not until late 2013 or even later.  And investing in BZ/CentralAuth is difficult given potential architectural plans.


 * "Make w:Template:Tracked an extension and use it to link back from bugzilla to relevant on-wiki discussions. Make it possible to 'watch' an issue through it." I believe Rob said this is also very difficult to conceive of doing as the next experiment due to the dev dependency.


 * The onwiki mailing list archives idea would be difficult, because mailing list software is a particularly gruesome area and one that the MediaWiki development community would probably shy away from attempting to work on. We'd want to find the FLOSS project that's doing mailing lists better than mailman is and get them to work on this, and is there such a project?


 * "More translation of tech documentation and updates" -- this could be interesting. By whom? How can we make the incentives work out right?  Could we possibly get the Legal & Community Advocacy team to work with us on this, with their new liaisons?


 * " Set up a wizard to guide people through the appropriate process and venue depending on what they want to achieve (on wiki? Bugzilla? i18n may be an issue)" - depending on implementation, this could be quite feasible! Would we be creating a decisiontree? Or would there be something something more complex?  I wonder whether this could be a gadget, or simply a page with some collapsible show/hide templated boxes, or something like that.


 * "Extend the StatusHelper gadget to include a button on hub pages to "Watch all projects on this page"." -- Requires development effort, so it'd be harder as an initial experiment.

Hope this is helpful! Sharihareswara (WMF) (talk) 00:45, 19 December 2012 (UTC)

Another mailing list thread to consider
Guillaume, I know this might take another couple of hours, but could you also reread the "Wikimedians are rightfully wary" wikitech-l discussion as you summarize stuff from mailing lists? I know it was this summer and not properly part of your autumn consultation. Thanks. Sharihareswara (WMF) (talk) 20:42, 24 December 2012 (UTC)