T137088: Recommendations to publish Product updates is related, or maybe just different perspectives on the same task?

This task started life as an idea to provide a product team template with status updates and history. That project was shelved when it became clear there was too much overhead to maintain such a template. Instead, we'd rather help users find the information where it is stored that fits the team's workflow.

This is live at https://www.mediawiki.org/wiki/Wikimedia_Discovery/Search

OK, thank you! I have some feedback.

The original request was "Product page template reflecting project status and history"

The actual changes are

• Adding an "Updates" field to Template:Wikimedia engineering project information.
• Adding a link to that field in Wikimedia Discovery/Search.

In T137226#2376977, @Keegan wrote:

This task started life as an idea to provide a product team template with status updates and history. That project was shelved when it became clear there was too much overhead to maintain such a template.

I was assuming (and I believe we discussed this, but my memory fails) that this was not about creating a new template, but about expanding Template:Wikimedia engineering project information with fields that would be only visible when filled, causing no disruption in the many pages where this template is used.

Instead, we'd rather help users find the information where it is stored that fits the team's workflow.

Yes, agreed. However, how can we best reflect project status and history in that infobox? A link to project updates helps a bit it is not everything. Following with the current draft of Communication milestones, the infobox could show which milestones have been reached and when, and whether there is any ongoing work or review to reach the next milestone.

For instance (Every entry would link to a subpage with the details about the milestone):

Progress: Ongoing - Beta feature release plan
          2016-06-24 Prototype released
          2016-04-23 Initial plan approved
          2016-01-01 Project idea announced

The example with Search pointing to Discovery updates is ok as an example, but note that "Search" is a generic project in maintenance, and the use case we want to resolve here is about the life of a new product or major feature. Also note that the updates linked refer to all Discovery activities, which cover a lot more than search. An example that would be more aligned with the rpoblem we are trying to solve would be a use of this template in CompletionSuggester pointing to the updates specific to this feature. The good news is that the original measurement of success doesn't require the implementation of the template in any real Product page, just a functional template ready to be used.

In T137226#2379377, @Qgil wrote:

OK, thank you! I have some feedback.

The original request was "Product page template reflecting project status and history"

The actual changes are

• Adding an "Updates" field to Template:Wikimedia engineering project information.
• Adding a link to that field in Wikimedia Discovery/Search.

In T137226#2376977, @Keegan wrote:

This task started life as an idea to provide a product team template with status updates and history. That project was shelved when it became clear there was too much overhead to maintain such a template.

I was assuming (and I believe we discussed this, but my memory fails) that this was not about creating a new template, but about expanding Template:Wikimedia engineering project information with fields that would be only visible when filled, causing no disruption in the many pages where this template is used.

Instead, we'd rather help users find the information where it is stored that fits the team's workflow.

Yes, agreed. However, how can we best reflect project status and history in that infobox? A link to project updates helps a bit it is not everything. Following with the current draft of Communication milestones, the infobox could show which milestones have been reached and when, and whether there is any ongoing work or review to reach the next milestone.

What we can do is only provide the space to give status and history updates, and see if the teams will even work with them. There is zero consistency between teams about milestone definitions, and as long as we continue to develop software in the manner that we do, there will not be consistency. It's best to keep this visible part of the template brief and portable.

For instance (Every entry would link to a subpage with the details about the milestone):

Progress: Ongoing - Beta feature release plan
          2016-06-24 Prototype released
          2016-04-23 Initial plan approved
          2016-01-01 Project idea announced

The example with Search pointing to Discovery updates is ok as an example, but note that "Search" is a generic project in maintenance, and the use case we want to resolve here is about the life of a new product or major feature. Also note that the updates linked refer to all Discovery activities, which cover a lot more than search. An example that would be more aligned with the rpoblem we are trying to solve would be a use of this template in CompletionSuggester pointing to the updates specific to this feature. The good news is that the original measurement of success doesn't require the implementation of the template in any real Product page, just a functional template ready to be used.

The issue here is that wiki pages fall out of date. It's their natural tendency; no one team is going to keep up with their updates and communications perfectly. Therefore, by developing the template system to reflect an expected perfection, we're actually setting up their pages to become outdated more quickly than they already would have. One missed month in updates due to vacations or other internal change will date the page and make teams look poorly on their attempts at communication.

I do not think it's good that we set up expectations this way.

In T137226#2379914, @Keegan wrote:

What we can do is only provide the space to give status and history updates, and see if the teams will even work with them. There is zero consistency between teams about milestone definitions, and as long as we continue to develop software in the manner that we do, there will not be consistency. It's best to keep this visible part of the template brief and portable.

Our exercise is to provide recommendations that are useful. Do you think the "Progress" timeline listing milestones would be useful?

According to https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Milestone_communication, we believe that projects will go through communication milestones. Adding one line to document a milestone doesn't seem a lot of extra work, and that line is what actually allows your users to find information about that communication milestone.

Consistency across teams would be desirable, but we can leave that to them. In any case all projects are announced and eventually deployed, with one or more stages in between (i.e. opt in for beta).

For instance (Every entry would link to a subpage with the details about the milestone):

Progress: Ongoing - Beta feature release plan
          2016-06-24 Prototype released
          2016-04-23 Initial plan approved
          2016-01-01 Project idea announced

The issue here is that wiki pages fall out of date. It's their natural tendency; no one team is going to keep up with their updates and communications perfectly. Therefore, by developing the template system to reflect an expected perfection, we're actually setting up their pages to become outdated more quickly than they already would have. One missed month in updates due to vacations or other internal change will date the page and make teams look poorly on their attempts at communication.

Wiki pages get out of date, but I don't see how that would be bad here. The workflow would be like this:

1. A team has a new project idea and documents it in a new project page. The template indicates this first action: "2016-01-01 Project idea announced"
2. Eventually, the discussion after the announcement has resulted in an initial plan that has been documented in a subpage. The template indicates this: "2016-04-23 Initial plan approved".
3. Eventually, there is a first prototype available for testing, and maybe an own subpage or a Phabricator task to collect feedback. The template indicates this: "2016-06-24 Prototype released".
4. Eventually, the software is getting in good shape and the team is working on a plan to deploy a beta feature to Wikimedia projects, documented in a subpage. The template indicates this: Ongoing - Beta feature release plan.

The team can go on vacation or can actually park the entire project and work on something else, and that Progress record and the related subpages would be still informative. Getting old, but still reflecting the status of the project. The only aspect that could become visibly obsolete is the "(ongoing)" work if the project has been parked and nobody remember to change that by "(stalled)" or "Cancelled", etc.

I do not think it's good that we set up expectations this way.

As I have tried to explain, I think the method propose brings little extra work when the team is actively seeking feedback, and it doesn't bring any penalization when the team is busy doing other things. I think it is a cheap and effective way to solve "Product page template reflecting project status and history" so that users could get a quick idea of what is going on.

Why not testing this idea with the new projects that Discovery and Collaboration are starting? Both will have new project pages where this template could be tested. For @CKoerner_WMF and @Trizek-WMF, adding the "Project idea announced" line would be trivial. And let's see how this evolves.

Opinions?

My opinion:

@Qgil I think it's a good idea for product teams to present more consistent info on the work they're doing. I don't think anyone would disagree. Keegan points out why it's only just an idea unless the product teams adopt it.

We (Community Engagement/Technical Collaboration) see it as useful, but product teams, I fear, do not. They see it as additional work with a small amount of benefit. Making small, incremental changes with teams that are willing, then reporting back the success/failures of those in hopes that other teams will adopt them is the best our team can do. We've been doing okay with the weekly updates in Discovery. For a few months now we've had a steady stream of updates from various team members. I'm still the one reminding folks on every Friday, putting together the week's wiki page, and writing and sending out the summary email.

If we're wanting a Product-wide adoption in a very quick period of time (measured in months if not single-digit years) we need someone to own that responsibility with a clear mandate from Product leadership, and buy-in from the teams, to get it done. Developers are gonna develop - this stuff always (hyperbole intended) falls to the wayside due to the pressures of "Real Work".

Some generic thoughts:

• WMF Product has a problem of collaboration and communication with communities. This is why we have the biggest portion of our team resources dedicated to support them through community liaison work and through the creation of a Technical Collaboration Guideline.
• We cannot assume that communication problems will be solved by writing a TCG if Product doesn't change anything on their end.
• We cannot assume that the recommendations of the TCG will be good if we model them after bad practices instead of good practices.
• Product will have a chance to review our recommendations and to provide their feedback, and to even skip them in specific circumstances or if they turn out not to be feasible.

But here goes a thought specific for this task: I don't think my proposal brings extra work for teams following the TCG (and modelling the TCG for the teams not following it doesn't make any sense).

The TCG says:

Products that are being developed have milestones for information that can be shared with the Wikimedia communities. Information sharing builds knowledge and trust - the product teams share what they have, and the communities share information about the milestone back.
...
After the information is communicated, community members then have the opportunity to respond with questions, comments, and concerns that will help the product iterate.
...
Must-have: A dedicated wiki product or project page, with a subpage of the product and/or project's page on mediawiki.org. The nutshell of the milestone information can be transcluded to the main page, with full text of the information on the subpage. The subpage also has the benefit of a discussion platform with the accompanying talk page.

Therefore, projects following the TCG have milestones that are announced on a date and with a URL pointing to more information and possibility to provide feedback. Once you have this, adding "2016-01-01 Project idea announced" to the infobox is a trivial task.

Even if we don't have standard milestones today, we can expect 3-5 milestones for the average product / major feature from beginning to deployment. Most products and major features supported by community liaisons do organize announcements seeking feedback around first ideas, prototypes, beta features, and deployments. If adding the line in the infobox is too much for the teams in this first phase, we could help them by doing that ourselves.

But in any case, I keep not seeing the unsustainable amount of work of maintaining this infobox for projects seeking community feedback.

For instance, at the new https://www.mediawiki.org/wiki/Edit_Review_Improvements @Trizek-WMF would just add to the infobox:

Progress:
Ongoing - User research, Design concepts.
2016-06-17 Project idea announced

We just have to ad these fields into the infobox.

In T137226#2393127, @Qgil wrote:

For instance, at the new https://www.mediawiki.org/wiki/Edit_Review_Improvements @Trizek-WMF would just add to the infobox:

Progress:
Ongoing - User research, Design concepts.
2016-06-17 Project idea announced

Are liaisons being asked to keep this information up to date for each department and team within?

No. We are defining recommendations for teams following the Technical Collaboration Guideline, not obligations for Community Liaisons. In fact, the purpose of the TCG is to help development teams to handle their interactions with the communities without needing a CL supporting them all the time.

Okay, I'm going to spin off a prototype that has a couple of fields for updates. Next quarter we can see about using it.

https://www.mediawiki.org/wiki/User:Keegan_(WMF)/Product_template_proto