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"

There's no right place, Andre, and we all know that. We ask for something to be fixed anywhere, and we're told to write a bugzilla, even for "high level" matters. And then if we write a bugzilla about an issue that nobody wants to address, we're told to join some mailing list that has no authority to address the issue, or post on some noticeboard that also has no authority to address the issue and probably isn't even being watched by anyone who *can* address the issue. Or we can post on MediaWikiWiki, where non-techs are pretty routinely ignored.

— Risker 2013-07-03 23:44:53 CEST

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 [1] that this is simply not possible for WMF at the moment. Deltahedron (talk) 18:46, 15 August 2014 (UTC)

The "standard, community-based process" [2] 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)" [3]. Anyone who thinks this process (if indeed is is a process at all) could be improved might wish to join the brainstorm at m: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)

The next frontier of transparency: give all the information to people in proprietary formats so that only friends with your own software preferences can access it. Nemo 08:29, 3 April 2016 (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/core }} 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

@Guillom: 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. m:Tech/Ambassadors and m: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 -> phab:tag/MediaWiki-API/. You can see some high-level goals in phab: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)

@Quiddity (WMF): The job openings are dynamically pulled from the latest monthly report, which means that currently they're already outdated by several months; it's probably best to link to the canonical location on the Foundation wiki. As for the links of projects and their short descriptions, they are also pulled from the project pages. The project pages and team hubs aren't really maintained, so that list is outdated as well. I agree that it would be nice to have an up-to-date, maintained list, but experience shows that that doesn't work. I feel it's best to link to the roadmap and encourage people to add descriptions to their Phabricator projects, for example. Another solution could be to have a bot maintain such a list based on the information that's in Phabricator, but I'm not volunteering to set that up :) Guillaume (WMF) (talk) 18:11, 27 March 2015 (UTC)

I put guillom's fine explanation of the roadmap vs. projects updates here at the top of Wikimedia Engineering/Project documentation howto, for now. -- SPage (WMF) (talk) 05:16, 25 March 2015 (UTC)

Since the dashboard is gone, how about quick links to teams'workboards at least? --Elitre (WMF) (talk) 16:07, 3 April 2015 (UTC)

I think that's fine, but it will still need to be manually updated (I'm not volunteering :) Guillaume (WMF) (talk) 16:57, 3 April 2015 (UTC)

Community Tech

I say that this is a sham. No WMF staff member will anything about it on the record. Waiting to make an appointment is simply an excuse for delay, and of course when the new staff member is appointed, they will have a steep learning curve, during which we will be asked again for further patience while nothing actually happens. The new team leader is being appointed by someone, and will report to someone, in the WMF hierarchy, who should already have determined the responsbilities for the new team and its leader. Have they nothing to say? Not to mere volunteers, it appears.

By contrast, this is how a real process works. There is a designated "incubator" who could and should have spoken up, as a courtesy to the community if nothing else, to say. "Hello, I'm AAA and I'm responsible for setting up the Community Tech team in conjunction with BBB who has responsibility for the department that team sits in and CCC who wrote the job description and determined the responsibilities for the new job, which you will find at page DDD. The teams responsibilities are EEE and the leaders are specifically FFF, but do not include GGG and HHH, with are being dealt with by teams III and JJJ: you will find a complete list of those teams and details of their respective responsibilities on page KKK. We are setting it the team now, the appointment process will complete by LLL and the new teams will start work on MMM. In the interim, as a temporary measure, we will collect community suggestions on page NNN, in a process which will be overseen by staff member OOO, who will collate responses and present them to the community and to the new team when they start work on MMM. In the interim, this message is being promulgated to the community by publication at PPP, QQQ and RRR: in particular, we are going to need translation volunteers, and they will be called for at SSS, TTT and UUU, initially to help out at page NNN. The new team will need to interact with the WMF software development design and decision process which you can find documented at VVV and WWW."

Did any of that happen? No, it did not. A real process, intended to effectively and efficiently interact with the volunteer community, would already have included, and published, all of those elements. I say and no member of WMF staff denies that this is not real, it is a sham. Didcot power station (talk) 18:05, 7 July 2015 (UTC)

Table reporting

I see that now Wikimedia Product contains a table with status updates, similar to what used to be done in /status subpages to be then transcluded in Wikimedia Engineering/Report subpages. Is it really more efficient to have a single table for everyone plus a series of periodic topical reports? Nemo 17:49, 2 June 2016 (UTC)

phabricator:tag/epic

"This tag is also used for goals identified in WMF's quarterly planning process, e.g. https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals ". Still correct? --Nemo 12:54, 14 March 2017 (UTC)