What is your understanding of "access to that project" exactly?

In T88468#1012372, @Krenair wrote:

What is your understanding of "access to that project" exactly?

Sorry for the confusion. By "access" I meant "administer", as in: add/edit columns to the board etc.

Otherwise, anyone should be able to view/add/edit the tasks in the project, move them across columns, etc.

Removing Project-creators tag until we figure out if this is what we need, as part of a wider discussion that also involves T88470: Create "report" project in Phabricator (to potentially replace WMF monthly engineering reports).

Pinging the Product team as suggested by Erik:
@Jdforrester-WMF, @Deskana, @DannyH, @JKatzWMF, @Maryana, @Tnegrin, this is a question for you:

Basically, we're looking for a system to surface "important" / noteworthy technical changes. Such a system would:

• make it much easier to assemble the weekly technical newsletter
• make it easier for everyone (including editors) to know what's going on without having to monitor every single task / bug / change
• and also probably allow us to retire the monthly engineering reports.

My first thought was to create a "Tech-News" tag and a "Report" tag, but they may duplicate each other.

What are your thoughts on a tag like "user impact", "noteworthy", "user delight" (no name is final)? Would you use such a tag? Would you prefer a set of more specific tags like "interface change", "old-pesky-bug", "performance improvement", etc.?

Can you clarify the audience? Are we looking for technical changes (such as
RESTbase deployment) that are interesting to an engineering focused crowd?
Or are these user-centered features that might appeal to editors?

In T88468#1027954, @Tnegrin wrote:

Can you clarify the audience? Are we looking for technical changes (such as
RESTbase deployment) that are interesting to an engineering focused crowd?
Or are these user-centered features that might appeal to editors?

If we go with a single tag, then the goal would be to highlight stuff for editors, but if we agree on a set of tags, then we can cater to audiences of different tech savviness. At the moment, I'm personally inclined to go towards the flexibility a set of tags offers, rather than a sub-par catch-all.

Also pinging @greg since this may make his work easier.

I like this idea generally.

• For the "tech news"/"report"/whatever tag I'd used that for things that are user-facing that I know about from the deployment roadmap (for things like Wikibase enabling, not for things like restbase v0 deployment)
  • Heck, it might be a requirement to get your thing on the deploy calendar...
• I'm not sure how much separation we need at the beginning at least into things like "interface change" or "old-pesky-bug" etc. Those tags have the problem of not being immediately guessable in the sense of "this task is important for others to know about, I wonder what I should tag it as". (This is one of the few times a hierarchy would be nice, but down with hierarchies!)
• I'd probably propose to copy the working style for things in the "breaking-change" category. See the discussion on wikitech "Who moved my cheese".

2cents

Thanks, @greg. I was also wondering if this system could address that wikitech-l discussion.

What about a #usernotice tag to use for tech news / deployment calendar etc., and a #devnotice or similar for breaking changes etc.? That way we keep things general and simple enough, but we still split by audience.

In T88468#1037411, @gpaumier wrote:

What about a #usernotice tag to use for tech news / deployment calendar etc., and a #devnotice or similar for breaking changes etc.? That way we keep things general and simple enough, but we still split by audience.

Not bad.

And where my mind is going on process/workflow:

• Someone adds one of those projects to a (presumably/hopefully still open) task
• They are put in the default column of their respective (user vs devnotice) workboard
• $responsible_persons triage those incoming tickets into the correct column
  • "Watch" - this isn't ready to go out yet (patch isn't merged/whatever)
  • "Next issue/release" - this thing is merged/going out and should be announced in the next Tech News or Breaking Changes notice
  • "Archive - where things go after that next issue/notice goes out

Am I over/under-thinking this?

@greg This is similar to the process I originally had in mind (above in the task description) so I think we're on the right track. I'll re-ping the product managers and also drop a note in the wikitech-l thread to make sure we're not missing something obvious :)

If we're going to have tags/projects for this, #user-notice, #developer-notice, and #sysadmin-notice would fit nicely with how we broadly define MediaWiki's audiences, I think (cf. https://www.mediawiki.org/wiki/MediaWiki).

However, I'm concerned that projects/tags are perhaps not the right approach here, at least for Tech/News. Manual curation isn't cheap, exactly. We can try to distribute the work of remembering to add a particular tag/project/flag/notice, but I think we're already kind of bad about adding such metadata to tasks. Finding a way to make Tech/News more automated is a good goal, but relying on humans to do something worries me. Humans are notoriously unreliable and inconsistent.

If projects/tags are the correct approach, it feels really non-obvious that "I want to add this to Tech/News" translates to #user-notice instead of #tech-news or #technews. We'd need to add an alias or two here for sure, I think.

I suppose the next step for this task would be to (more formally) flesh out exactly what any new projects/tags would be and their descriptions. I'm not sure this task should be marked as stalled.

In T88468#1042470, @MZMcBride wrote:

However, I'm concerned that projects/tags are perhaps not the right approach here, at least for Tech/News. Manual curation isn't cheap, exactly. We can try to distribute the work of remembering to add a particular tag/project/flag/notice, but I think we're already kind of bad about adding such metadata to tasks. Finding a way to make Tech/News more automated is a good goal, but relying on humans to do something worries me. Humans are notoriously unreliable and inconsistent.

The way Tech News is currently assembled is entirely manual, and it's mostly done by a single person, although other people occasionally add an item to the next newsletter themselves.

By providing a mechanism in Phabricator to tag those changes, I'm hoping to make the process more reliable and consistent than it is today.

If projects/tags are the correct approach, it feels really non-obvious that "I want to add this to Tech/News" translates to #user-notice instead of #tech-news or #technews. We'd need to add an alias or two here for sure, I think.

Good point. In addition to aliases for #technews, it could also make sense to have a generic #notice tag that people can add when they don't want to bother figuring out in which category the item falls. There could be a lightweight triage of #notice to add more specific notices as appropriate.

I suppose the next step for this task would be to (more formally) flesh out exactly what any new projects/tags would be and their descriptions. I'm not sure this task should be marked as stalled.

Fair enough. Here's a proposal:

• #notice should be added to any item that is noteworthy, disruptive, or otherwise impacts someone's workflow. It should be used liberally on a "tag it and forget it" basis. Items in this category will be triaged regularly (at least on a weekly basis as part of the writing of Tech News) and put into one or several of the more specific notice categories. The #notice workboard should be empty after each triage.
• #user-notice will be for any item that is of interest to Wikimedia editors. Its scope is similar to that of Tech News, i.e. "recent software changes likely to impact Wikimedians". Its workboard will include several steps to help assemble Tech News, and to provide information similar to monthly engineering reports. For example, I can imagine the following columns: Backlog, Next Tech News, Future Tech News, Recent Tech News, and Archive.
• #developer-notice and #sysadmin-notice would work the same way, but for their respective audiences (developers of the MediaWiki ecosystem, and maintainers of third-party MediaWiki installations). The items that appear in those projects will notably help assemble the release notes.

How does that sound?

(Side note: The "stalled" status refers to the Project-Admins project, because it's not actionable yet in that context. The discussion is indeed not stalled.)

I love it. Tagging Phab tasks as Notice sounds a lot more sensible than manually copying stuff to emails and mediawiki.org pages. It will save a lot of people a lot of time.

I like the concept. Plus might also help to create release notes in the long run.

The social part (making teams and devs aware and teaching them actually use it) will be much harder though - it's like the very same neverending task to make people remember that there is an "easy" tag and that they can actually set it on tasks.

Longer version: For a short moment I was thinking I'd prefer a #notice-* scheme but that could be set as secondary tags if wanted, plus apart from being listed together in https://phabricator.wikimedia.org/project/query/active/ there's no other gain ("Projects" dropdown handles dashes as a token seperator just fine and the only match for "noti" is "Echo" so far, hence not too noisy), so I dropped that thought again.

I like the idea very much BUT I would start with something simple, clear and explicit:

Add the User-notice tag to a task if you want to propose it in the next Tech News.

Then we can see how it works, and whether we need to rename existing tags or create new ones.

In T88468#1049632, @Qgil wrote:

I like the idea very much BUT I would start with something simple, clear and explicit:

Add the User-notice tag to a task if you want to propose it in the next Tech News.

As explained above, Tech News is only for Wikimedia editors, and doesn't cover many other kinds of noteworthy changes. #notice is more general and easier to remember IMHO. And we need the three sub-tags to triage #noticed tasks according to their audience, otherwise the whole proposal breaks down.

We don't know how much people will use the tags, but we know they won't use them if we don't create them.

In T88468#1049377, @Aklapper wrote:

The social part (making teams and devs aware and teaching them actually use it) will be much harder though

Yep. But we won't know unless we create them :)

Longer version: For a short moment I was thinking I'd prefer a #notice-* scheme

I'm fine with that idea as well, and might help see them as sub-tasks. I'm fine with either scheme.

@Aklapper Do we need to do anything else to move forward with this (and T88470#1054821) ?

Per IRC Consensus™:

let's go with Notice, User-notice (with aliases User-notice and User-notice), Developer-notice and Sysadmin-notice

Thank you @Aklapper!

Is there any reason for these tags to be lowercase? I thought all tags had been standardised on sentence case (with uppercase first letter).

I'm not aware of any standardization on sentence case.

https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Name says

Title case by default.

Some context: https://www.mediawiki.org/w/index.php?title=Phabricator/Help&diff=1172505&oldid=1171804 and T283: Document a process to request new projects.

I really have no preference either way as long as the existing tags continue to work :)