Talk:Wikimedia Engineering/Archive 1

Design
The page could certainly use some design love. Feel free to edit mercilessly as long as the information hierarchy is preserved. guillom 09:49, 10 November 2011 (UTC)
 * I think it looks great! Thank you!    Thorncrag    19:34, 16 November 2011 (UTC)
 * Better late than never: The page now looks pretty enough :) guillom 15:18, 9 July 2014 (UTC)

"Or we can post on MediaWikiWiki, where non-techs are pretty routinely ignored"

 * Apart from generalizations and the implication of "we vs. them" in above quotation that I do not share: Personally I cannot judge how welcoming each forum or corresponding mailing list is, simply because I am not on every mailing list and cannot follow every wiki discussion/talk page, and I'm sorry to hear that other places that would be more appropriate to discuss high level issues don't feel useful. I can only repeat that Bugzilla is a bugtracker where specific issues or code enhancement requests are discussed. That's the scope of a bugtracker, and when maintainers decide that an issue will not get fixed, that's the maintainers' decision. Generalizing by using disagreement on a specific decision for questioning strategic priorities of a company or organization is simply out of scope for a bugtracker, as that's not a software bug or software enhancement request anymore. My guess would have been https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum here, and I hope that Risker will find a place where Risker's concerns receive appropriate attention. --AKlapper (WMF) (talk) 20:38, 7 July 2013 (UTC)
 * I have certainly found that there's always one more page to post at. Perhaps it might help if there were members of staff whose job included gathering requirements from the contributors and other volunteers, and liaising between the community and the staff.  We could call them Community Liaison.  Unfortunately it has been explained to me  that this is simply not possible for WMF at the moment.  Deltahedron (talk) 18:46, 15 August 2014 (UTC)
 * The "standard, community-based process" is "whenever you have a great idea involving something technical, that you share the idea with the rest of your community at one of the Village Pumps (or some other centralized forum). If the rest of the community is interested, they'll point you to the right place (whether that's a bot request page, Bugzilla, or somewhere else)" .  Anyone who thinks this process (if indeed is is a process at all) could be improved might wish to join the brainstorm at Community_Engagement_(Product)/Process_ideas.  (For various reasons I will not be able to contribute there).  Deltahedron (talk) 18:23, 6 September 2014 (UTC)

Identifying when it's too late
One reason it's hard to get user participation on MediaWiki software development is that this wiki's main namespace is full of many ideas thrown by paid developers, often uncategorised and/or lacking an infobox, whose stage of development is incomprehensible. Often an idea lingers for a while, or receives an inordinate amount of thinking/work by the proposer, and readers' interpretations will range from "it's a mere boutade" to "it's an irreversible decision enshrined in our fate". Commenting or working on embryonic ideas is laborious, so only people infatuated with the idea will comment.

Some ideas, however, have the invisible property of being really wanted by the powers that be: either intrinsically, or just for having received too high a personal investment to be abandoned. So at some random point in time they start being designed, and it's too late to comment on the basic idea; then at some other random point in time they start being implemented, and it's too late to comment on the design; then at some random point in time they start being put in use, and it's too late for about anything. Adding to confusion, those random points in time are not recognisable either, because what seems a finished product to some is a mere proof of concept for others. One thing is easy to see: the moment when something is thrown into your face (enabled for you on your wiki).

So, what can we do to make it clear in what stage an idea/proposal is and when it will be too late to do X?

How to tell someone "please, just trash this idea"? Or "thanks for the design proposal but it's not for us"? Or "thanks for the implementation but please stop"? Or (hopefully never) "ok I realise it's ready but we need to cut losses and give up with it"? --Nemo 12:42, 9 August 2014 (UTC)
 * Your post taught me the word boutade. I'm pretty excited about that. Thanks! --MZMcBride (talk) 00:32, 12 August 2014 (UTC)

Nemo, a useful question. (I'm sure you know this and it doesn't make things better, but people involved in planning and designing projects ask similar questions. And the related question of identifying when it's no longer time -- when an established Thing should be reëvaluated and possibly discontinued.)

I would find it helpful to have a standard infobox that's about 3x as detailed as the current ones, including a subset of:
 * Project parent / predecessor / successor / sibling
 * Inception date / lead maintainer / status
 * Link to bugzilla/phab search for all related items
 * Link to code and testing repos
 * Link to acceptance criteria, unit tests, data
 * Link to overview of feedback (for major releases)
 * Link to a timeline/roadmap
 * Cutoff dates for basic idea, design, alpha, early eval, beta, late eval, soft launch, full launch
 * Image of mascot wrestling with project-icon

A related infobox or navbox would be handy for an overview page for each cluster of related tools and ideas. They would be organized around a shared roadmap and goals, perhaps one or two teams, and would have some higher-level timelines: some projects depend on others.

Some entries could be color-coded based on status or the results of the evaluations, or whether the date indicated had been met or changed.

Which of the current project pages are the most informational / offer the best prototypes for this sort of structured data? Sj (talk) 01:04, 3 September 2014 (UTC)
 * What Sj mentions does sound like a good idea, although one thing that may be critical is curation of abandoned projects. I am going to guess that you may end up with a lot of projects that are in the design phase, and the developer becomes inactive for whatever reason, after a certain point there should be a mention of the fact that the project is inactive. In the past, I feel like I have seen a lot of interesting projects where I later found out it was a Google Summer of Code thing that was never completed or the developer left the foundation, of course that might be my imagination exaggerating a few cases Jztinfinity (talk) 20:57, 20 September 2014 (UTC)

The way BeWelcome manages its process to introduce new features is interesting. The whole process is a community discussion; there are some pages where issues are identified, ideas to solve these are proposed and improved, then a vote takes place to select the best solution, and then development is requested and executed. The whole process is integrated in their software with a sort of customised forum. ~ Seb35 [^_^]  18:45, 21 September 2014 (UTC)

Did anything happen in August 2014?
Yes, it seems that some things did: Wikimedia Engineering/Report/2014/August. For some reason that didn't get transcluded onto the current version of this page, which still thinks that July 2014 is the latest news. I don't understand the templates well enough to fix it. Deltahedron (talk) 20:20, 6 September 2014 (UTC)
 * Because it's still a draft, as the empty sections and "FIX" boxes may have hinted. --Nemo 15:53, 7 September 2014 (UTC)
 * Nonetheless it has the "Major News" section, which is what could have been transcluded to this page, and which is what would have been helpful to the reader. Deltahedron (talk) 16:04, 7 September 2014 (UTC)
 * I think a published report is better. --Nemo 16:45, 7 September 2014 (UTC)


 * Sorry, I had forgotten to add the draft template to the August report. As Nemo mentioned, it's still a work in progress. The "Major news" section may be ready, but the "Read more" link would still link to a draft, so I prefer to wait until the report is ready before updating Wikimedia Engineering/Report/latest. guillom (talk) 09:10, 8 September 2014 (UTC)


 * Ah, I see. Thanks for clarifying that.  Deltahedron (talk) 17:15, 8 September 2014 (UTC)
 * No problem. Thank you for caring enough to ask :) guillom (talk) 19:31, 8 September 2014 (UTC)

Green ToC links
Re: the links at the top of the Wikimedia Engineering portal, ("Platform Features Mobile Language Analytics") - those are currently links to other pages. However at the other portals, e.g. Tech/Ambassadors and Tech/News, those colored links are Table of Contents equivalents (they only lead to #subsections of the same page). So, I'd suggest replacing those links with a more ToC-like list at the top. Just a thought. :) Quiddity (WMF) (talk) 00:02, 11 February 2015 (UTC)

Moving to Phabricator
Most WMF teams and many MediaWiki projects now track their work in Phabricator, e.g. API/Architecture work/Planning -> tag/MediaWiki-API/. You can see some high-level goals in tag/Roadmap/ I'm not sure what this means for these pages or all the Wikimedia engineering templates-- SPage (WMF) (talk) 19:31, 19 March 2015 (UTC)
 * I hope the other (more static) contents of this main portal will remain, somewhere, in some form.
 * The sidebar sections (e.g. "Job openings", "Get involved") are very important. Also the links & short-descriptions of all the WMF engineering teams, are not found collected together anywhere else (afaik).
 * However, perhaps some of this will move elsewhere when the (stalled?) MediaWiki/Homepage_redesign gets moving again? (though I grok the difficulty with mixing Mediawiki and WMF details on the main page... :-/ )
 * I do agree with the rest of the cleanup/de-duplication though (here and the linked dept/team pages). Good stuff :) Quiddity (WMF) (talk) 20:54, 24 March 2015 (UTC)