In T139210#2426206, @Jdlrobson wrote:

Out of curiosity - does Phabricator allow you to delete/merge tags/projects (rather than just archive)?

Nope. (Unless some difficult set of SQL queries ran directly in database to totally get rid of it and all its references.)

We already have trouble finding projects (T76732: Exact matches should always win when suggesting/auto-completing, T99739: Phabricator project auto-complete is arbitrary (in a bad way)), so adding a ton more entries will make things worse. That's the main reason I favor having *some* controls over project/tag creation. Not a heavy process, but something.

If auto-complete were a lot smarter, or if people could customize a whitelist and/or blacklist of projects/tags, I could probably support being much more permissive with creation of new ones.

These are bugs in the software. Should a process that hinders getting things be kept alive simply to workaround such issues? If I've learned anything from software development increased pain / friction with bugs is always a good thing that leads to a push for resolution in some way.

fwiw I agree the project creation policy needs to either go away or be significantly streamlined.

Removing Team-Practices because it's not something the team would take action on. I will remain subscribed as an individual.

I'd be very hesitant to open up project creation to more users until (a) tags can be deleted outright, and (b) project/tag creations are logged in some publicly-viewable place by the Phabricator software.

@TTO:

a) Why do tags need to be deleted as apposed to archived?
b) newly created projects.

@TTO Also T103700: LOG: Phabricator project creation.

@Aklapper Returning #rfc as it is wide public discussion.

@Danny_B: This affects a few dozen people creating projects in a single Wikimedia website called "Phabricator". Hence it's not really wide. #RfC is for a "task needs input and discussion in the style of a request for comments" and I do not see us following mw:RfC here. Hence I'd remove the tag again, otherwise nearly every task could become a 'request for comments'.

Unlike most of the tasks which are focused on work of narrow group of people, this one directly or indirectly affects every single user of Phabricator.
Please avoid using of slippery slopes.

@Jdlrobson: Thanks for creating this task.
I haven't commented so far because I've been wondering what's my fears.
Reminded myself that FLOSS development is a bazaar and not a cathedral so one could only find approaches to decrease untidyness, and some of these approaches can easily become too heavy-weight. Like in this case. Abandoning the policy would be a bigger change in paradigm (just saying, not judging).
(I don't think the WWW and Twitter examples above fit well as we're after organizing work. )

• Following changes: For those people who want to/should be aware of changes (e.g. to do gardening), This query shows the latest created projects so I assume this also covers abandoning T103700? And we have the weekly email listing project/policy changes etc in Phabricator.
• Awareness of projects: How to still make other folks aware which tags to use (or not to create, as those tags already exist and just use a different word) so we don't end up in duplication? But that problem already exists now and could just be handled by streamlining the process to make people check for already existing projects before going ahead, or act by archiving after creation of a duplicate tag. Hence not a new situation created by abandoning / streamlining the process.
• Challenging a new project: If someone created a new project and someone else feels a need to discuss, anybody can access "$Project > Manage > Project History" to find out who created a project and contact the person. We'd need to define a venue for such discussions though - creating a Phabricator task, post-project creation?
• Bugwrangler expectations (currently unclear to me): Does abandoning/streamlining the process imply that people don't expect the bugwrangler to be aware of all projects out there and set them accordingly on tasks?
• Completeness of search results / Identifying abandoned projects: If I was a new contributor and I searched for open tasks with a certain project associated, I'd ideally expect a complete list of tasks. That is already not the case but I'd be afraid it would be even less of the case. Hence tagging needs to happen. (For example, Mozilla Bugzilla has >600 keywords and noone knows them or consistently sets them. But Bugzilla does not allow archiving them, just explaining where my thinking comes from.) So in the long run I expect us to have more 'forgotten'/abandoned projects in Phabricator and more reports against those projects which won't receive feedback (but that's already the case for Git code repositories with maintainers AWOL). Wondering how to identify them for cleanup.

So if we streamlined, I'd currently imagine (please feel free to challenge) that we

• still keep the type of projects,
• keep (shorter) instructions how to come up with a good project name,
• explicitly ask to query for existing projects before creating a new one,
• explicitly ask people to write a project description that can be understood by an outsider (no "we" in "we use this project to do foo", do include web links to more info about the project) as Phabricator is a public place,
• and "if you expect some non-public information in tasks in your project, file a task so we can sort that out and check if you might need also a Space. Do not fiddle with the View/Edit policies, they only apply to projects but not to tasks in projects"?

For what it's worth, here's some context on why Phabricator's projects are fairly heavyweight. (I may be misremembering some details, but I think most of this is about right.)

At Facebook circa 2009ish, the internal "Tasks" tool at Facebook had very lightweight tags that worked more like Twitter hashtags: anyone could create a new tag, and you added a tag by just typing the name of any tag you wanted -- if one didn't exist yet, it was automatically created inline without even prompting you.

By 2011 when I was writing Maniphest, I believe the Tasks tool had about 200,000 distinct tags, including many misspelled tags, pretty much any short sequence of characters, etc. I recall that it was very difficult to browse them or identify which ones were meaningful, and anything you typed returned hundreds of indistinguishable results.

It was actually worse than this, because the Platform Abuse team had used tags to keep track of Facebook platform applications (which were being reviewed or had been reported, or something like that) by tagging tasks with application names. When a user reported an issue with the "AgricultureVilla" application, abuse team members could search for that tag to identify other reports of the same application. So every platform application which had been reported had a corresponding tag with the application's name.

However, many of the applications that were reported for violated policies were flagrantly abusing policies and didn't have names like "AgricultureVilla" -- instead, they had names like "Boobs CLICK HERE Boobs Free NOW CLICK!!! Boobs Sex". This was entered verbatim as the tag for the application.

There were a lot of these tags -- more than any other type of tag -- so almost anything you typed mostly returned sex/drug results as suggestions. (In a similar vein, Facebook later launched an unfiltered "interest" typeahead based on existing user data that suggested interests like "murder" and "smoking crack".)

Anyway, I made Phabricator's tags more heavyweight partly in response to seeing very lightweight tagging completely degrade to uselessness at Facebook in the context of organizing a body of tasks.

Thanks for the very helpful context @epriestley. And thanks @Aklapper for the bug-wrangler's perspective and lots of related context.

Clearly we want to find some happy medium between two extremes:

1. 200,000+ distinct tags about anything and everything (now with more nonsense tags!)
2. Totally restricted/scrutinized process with a tag committee to approve tag RFCs and everybody gets a veto vote.

With the current restrictions, I feel like we are leaning a bit too heavily towards 2. In my not so humble opinion, we (the Wikimedia Foundation and The Community) often end up with heavy-weight processes in places where a much simpler solution would be more efficient and sufficient. It's not just in our tag creation process, code review is another example and there are many more.

More to the point of this task:

By streamlining the existing process we should be able to strike the right balance, We just need to optimize things so that tag creation isn't too restrictive or difficult without encouraging total anarchy as described by @epriestley (above).

Some of the most problematic challenges I see are around namespacing some of the more prolific / less-generally-useful tags:

• Currently we have a bunch of teams creating milestones which most people outside the team don't care much about.
• Release-Tagger-Bot creates weekly release tags which are generally useful but they are ugly and numerous
  • related problem: these aren't actually milestones because the bot predates milestones
• Projects are used for a bunch of different things and project type icons/colors are only partially standardized. ** We probably need to take another look at the project types we have documented, continue to fix outliers and expand the list of standardized project types.
  • Several tasks are already being discussed to improve this situation and we've been making good progress AFAIK.
• It would be nice to be able to modify the query that powers tag autocompletion / typeahead UI to ignore some project types from the results.
  • I don't know if upstream is open to this type of customization (unlikely due to policy against new config options) but it's certainly something we could customize in our forked codebase.

In T139210#2472729, @mmodell wrote:

• Currently we have a bunch of teams creating milestones which most people outside the team don't care much about.
• Release-Tagger-Bot creates weekly release tags which are generally useful but they are ugly and numerous
  • related problem: these aren't actually milestones because the bot predates milestones

• Does ReleaseTaggerBot only tag WMF deployments (a la WMF-deploy-2016-07-12_(1.28.0-wmf.10) or also supports other projects with their own milestone schemes?
  • If the latter: Would you like to create a task to make ReleaseTaggerBot create milestones (assuming the API allows)?
  • If the latter: Could ReleaseTaggerBot automatically archive a milestone after a certain time (currently this seems to be done manually) to remove the milestone from typeahead proposals?
  • If the former: I assume this problem will get solved by fixing T89945: Merge to deployed branches instead of cutting a new deployment branch every week.?

• It would be nice to be able to modify the query that powers tag autocompletion / typeahead UI to ignore some project types from the results.
  • I don't know if upstream is open to this type of customization (unlikely due to policy against new config options) but it's certainly something we could customize in our forked codebase.

Could you come up with a summary / potential proposal in a dedicated task (if not exist yet)?

In T139210#2491737, @Aklapper wrote:

In T139210#2472729, @mmodell wrote:

• Currently we have a bunch of teams creating milestones which most people outside the team don't care much about.
• Release-Tagger-Bot creates weekly release tags which are generally useful but they are ugly and numerous
  • related problem: these aren't actually milestones because the bot predates milestones

I can make them milestones, it just needs someone to decide what the parent project is. :-)

• Does ReleaseTaggerBot only tag WMF deployments (a la WMF-deploy-2016-07-12_(1.28.0-wmf.10) or also supports other projects with their own milestone schemes?

It currently only supports the former, but other schemes could be written. There's already T100814: Have ReleaseTaggerBot also tag versioned libraries we control for libraries, for example; that task could be expanded for other areas.

• If the latter: Would you like to create a task to make ReleaseTaggerBot create milestones (assuming the API allows)?

Currently the projects are manually created (by me), not by the bot; back then, we weren't sure we wanted to give it project admin rights as it was a simple test. A task to do this already exists: T100812: Have ReleaseTaggerBot automatically create new deploy branch (release) projects.

• If the latter: Could ReleaseTaggerBot automatically archive a milestone after a certain time (currently this seems to be done manually) to remove the milestone from typeahead proposals?

I manually archive them when they're no longer on the cluster; this could be automatic, yes.

• If the former: I assume this problem will get solved by fixing T89945: Merge to deployed branches instead of cutting a new deployment branch every week.?

You say "fix", I say "will break a critical workflow". :-(

Since this is getting a bit off-topic, I'm creating a separate task: T141278: Decide how ReleaseTaggerBot fits into the brave new world of long-lived-branches

Any further comments / feedback on T139210#2470135, T139210#2472338 and T139210#2472729?
e.g. @Jdlrobson (as you created this task)?

My feeling is we are still too extreme.
We can avoid this problem. The main bit of the process I dislike is the need to debate projects and open tickets to justify why they are needed.

There seems to be various types of "project"

1. Extensions (e.g. MobileFrontend )
2. Tags for internal housekeeping e.g. Mobile
3. Goal projects (e.g. VisualEditor-ContentEditable)
4. Team specific sprints e.g. Reading-Web-Sprint-79-Uh-oh
5. Backlogs for projects managing more than one project Web-Team-Backlog

I'd like for us to explore a few changes:

• #1 handled as part of the setting up a repository workflow
• #3 #4 and #5 to happen without a workflow by anyone who has the right permission without being required to log its creation, provided they prefix it with an existing project name (I'm not sure if there is a way to add validate the prefix of tags)

For #2 I'm not sure what the solution is. I don't want to tags to become useless, but I'd hope that most tags we need are covered or can be covered with the existing process.

In T139210#2541455, @Jdlrobson wrote:

There seems to be various types of "project"

1. Extensions (e.g. MobileFrontend )
2. Tags for internal housekeeping e.g. Mobile
3. Goal projects (e.g. VisualEditor-ContentEditable)
4. Team specific sprints e.g. Reading-Web-Sprint-79-Uh-oh
5. Backlogs for projects managing more than one project Web-Team-Backlog

#3 and #4 should probably be milestones and should not require tasks or discussion outside the parent project since milestones are scoped to the project namespace.

In T139210#2541685, @mmodell wrote:

In T139210#2541455, @Jdlrobson wrote:

There seems to be various types of "project"

1. Extensions (e.g. MobileFrontend )
2. Tags for internal housekeeping e.g. Mobile
3. Goal projects (e.g. VisualEditor-ContentEditable)
4. Team specific sprints e.g. Reading-Web-Sprint-79-Uh-oh
5. Backlogs for projects managing more than one project Web-Team-Backlog

#3 and #4 should probably be milestones and should not require tasks or discussion outside the parent project since milestones are scoped to the project namespace.

I agree that a goal project should be a milestone. However, note that the example given isn't a goal project. :-)

@Jdforrester-WMF: right, it's a sub-component which could be a sub-project but we just haven't bothered to mass-migrate to subprojects yet.

Bottom line: the main concern is the proliferation of tags, which puts in risk the usefulness of tags at all.

In T139210#2541455, @Jdlrobson wrote:

There seems to be various types of "project"

1. Extensions (e.g. MobileFrontend )

I'd like for us to explore a few changes:

• #1 handled as part of the setting up a repository workflow

Isn't this already the status quo?

In T139210#2547267, @Legoktm wrote:

In T139210#2541455, @Jdlrobson wrote:

There seems to be various types of "project"

1. Extensions (e.g. MobileFrontend )

I'd like for us to explore a few changes:

• #1 handled as part of the setting up a repository workflow

Isn't this already the status quo?

If not explicitly it is implicitly. And these (mw extension projects, or a new service project) should be an uncontroversial creation.

If it's uncontroversial then why have a policy requiring people to seek consensus ahead of time? This is yet more evidence that the policy is overly restrictive. The result is that something which should take 30 seconds instead takes days, or you just ignore the policy and create the uncontroversial project while feeling guilty about violating a policy.

In T139210#2549335, @mmodell wrote:

If it's uncontroversial then why have a policy requiring people to seek consensus ahead of time?

I don't think there is that requirement (for the case @Legoktm highlighted).

From https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#New_projects

If you are a member of acl*Project-Admins:

• Is the project of the type "ACL" (e.g. for a Space)? If so, file a task to propose and discuss the project before you create the project.
• Is the project of the type "sprint" or "release"? Go ahead and create the project.
• Is the project of any other type? Create the project and document its creation by adding a comment to T103700.

Now, that is only for those in that acl group. However, everyone who can create git repos should also be in that acl group and just create the associated project as well.

In T139210#2549335, @mmodell wrote:

If it's uncontroversial then why have a policy requiring people to seek consensus ahead of time? This is yet more evidence that the policy is overly restrictive. The result is that something which should take 30 seconds instead takes days, or you just ignore the policy and create the uncontroversial project while feeling guilty about violating a policy.

In T139210#2549381, @greg wrote:>

I don't think there is that requirement (for the case @Legoktm highlighted).

From https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#New_projects

If you are a member of acl*Project-Admins:

• Is the project of the type "ACL" (e.g. for a Space)? If so, file a task to propose and discuss the project before you create the project.
• Is the project of the type "sprint" or "release"? Go ahead and create the project.
• Is the project of any other type? Create the project and document its creation by adding a comment to T103700.

Now, that is only for those in that acl group. However, everyone who can create git repos should also be in that acl group and just create the associated project as well.

One of the core issues to me here seems to be that the process is confusing and the requirements for what needs proposal, etc. are deep in a mediawiki page. Having to look up the policies and parse through all that text is time I'd rather spend working forward on research/design/build.

One of the core issues to me here seems to be that the process is confusing and the requirements for what needs proposal, etc. are deep in a mediawiki page. Having to look up the policies and parse through all that text is time I'd rather spend working forward on research/design/build.

@atgo +1

In T139210#2549398, @atgo wrote:

One of the core issues to me here seems to be that the process is confusing and the requirements for what needs proposal, etc. are deep in a mediawiki page. Having to look up the policies and parse through all that text is time I'd rather spend working forward on research/design/build.

Fair point. I think for @Jdlrobson original list of 5 things (Extensions (e.g. MobileFrontend ) projects, Tags for internal housekeeping e.g. Mobile, Goal projects, Team specific sprints e.g. Reading-Web-Sprint-79-Uh-oh, and Backlogs for projects managing more than one project Web-Team-Backlog) that the only one that needs any kind of discussion is tags (eg Mobile). The rest just documented (which really, we can probably remove that document requirement (since you can search for projects sorted by newest first: https://phabricator.wikimedia.org/project/query/22EYiEgxyyHN/#R )).

Much of the documentation was created, as best as I can tell, to help people coalesce around our best practices (eg: colors and icon standardization, see https://www.mediawiki.org/wiki/Phabricator/Project_management#Types_of_Projects ). I think that should continue to be documented (having those be standardized is A Good Thing), but reducing the bikesheding is also needed.

tl;dr: Yup, let's streamline the documentation (as @Aklapper laid out way up in T139210#2470135, probably) and make it clearer/easier for people to do the quick/managerial work like what @Jdlrobson and @atgo are talking about.

@greg sounds like a great start. Thank you.

Our on-wiki docs were written before the sub-projects and milestones feature got implemented in upstream Phabricator earlier in 2016, and that new feature received a separate on-wiki documentation section unrelated (disconnected?) from 'Types of Projects'. Which I consider part of the bigger problem to tackle in this task (e.g. deprecating top-level 'sprint' and 'goal' projects in favor of subprojects/milestones).

Planning to come up with a proposal this week (if nothing more urgent comes across).

I guess we could open the project creation part to all Wikimedia employees and have a whitelist for volunteers who help out in phabricator to prevent spam from spam bots.

This will be like what we do with integration/config but instead for phab project creations.

Does everyone like that idea?

@Paladox: we already do something similar, that's what Project-Admins is for.

@mmodell oh, could I be apart of that group please?

In T139210#2621932, @Paladox wrote:

@mmodell oh, could I be apart of that group please?

T706: Requests for addition to the #acl*Project-Admins group (in comments) is the appropriate place to request permissions.

Ok sorry

Attempting to summarize. Feedback please (and answers to questions).

• Creation of (future) projects:
  • Choose a project type:
    • Parent/top-level projects
      • Component (Default) && Umbrella: mostly organizing around code bases or functional areas within a code base. Use Umbrella icon if that's not the case.
      • Tag: Crosseverything; Only type of project that needs to be discussed beforehand
      • Team
      • User-* / Personal
      • Sprint, Release: Deprecated as top-level projects, use subprojects and milestones instead
      • Special cases you don't need to deal with: Patch-For-Review, meta-*, acl*
    • Subprojects and Milestones
      • Previously Sprint and Release. If for some reason a subproject is not wanted for a sprint or release (e.g. subproject won't be on workboard etc and Herald rules would not help due to T144041), follow the icon+color guidelines.
    • Space: If you need to restrict access to all tasks in a project to a static group of people.
  • General expectations and recommendations:
    • Name and description of project need to be good; potential prefixes? (see questions below); dashes recommended but no 'must'.
• Logging of newly created projects
  • Abandon T103700, use query.
• Challenging a newly created project:
  • Fix minor problems yourself; contact owner in tasks for more complex problems.

Questions:

• Goal projects: Cannot easily put them under "Subprojects" as there might not always be exactly one parent. (Personally I'd kill goals as it's a bastard of a sprint and a component and I don't know why to differentiate).
• Legacy related: Potential manual conversion of existing top-level sprints etc to subprojects? For example all User-* projects could be subprojects of a generic "User projects" parent, or all tools on Tool Labs, but is the gain high enough (listing in search results etc), plus it's getting blurrier in other areas.
• Naming schemes: Directly related to previous item. Some prefix (like "MediaWiki-extensions-*" from Bugzilla times, Chapter projects like "WMUA-*", etc) or not? Also see T144111#2613084 about names of projects that are tools on Labs.
• What's the future of the Project-Admins group? Abandon and let anyone create projects? Mentioning T84 due to concerns.

Related docs:

• https://www.mediawiki.org/wiki/Phabricator/Project_management#Types_of_Projects
• https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects
• https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects/Project_types

In T139210#2628151, @Aklapper wrote:

• • Special cases you don't need to deal with: Patch-For-Review, meta-*, acl*
• Space: If you need to restrict access to all tasks in a project to a static group of people.

ACL projects/spaces should still go via project-admins, we don't want anyone setting up a space just to transfer currently-public tasks in - we'd have no way of pulling them back out.

In T139210#2628151, @Aklapper wrote:

• Challenging a newly created project:
  • Fix minor problems yourself; contact owner in tasks for more complex problems.

Fix minor problems yourself if possible, contact the owner otherwise, or if that doesn't work create a Project-Admins task.

In T139210#2628151, @Aklapper wrote:

• What's the future of the Project-Admins group?

Reduced in scope - some things will still need to be discussed beforehand like tags, special cases listed above, etc.

In T139210#2628151, @Aklapper wrote:

Abandon and let anyone create projects?

No, per what I wrote above

In T139210#2630586, @Krenair wrote:

ACL projects/spaces should still go via project-admins

Indeed.

In T139210#2628151, @Aklapper wrote:

• Challenging a newly created project:

Fix minor problems yourself if possible, contact the owner otherwise, or if that doesn't work create a Project-Admins task.

That probably scales better, yeah.

In T139210#2628151, @Aklapper wrote:

• What's the future of the Project-Admins group?

Reduced in scope - some things will still need to be discussed beforehand like tags, special cases listed above, etc.

Abandon and let anyone create projects?

No, per what I wrote above

Regarding the permissions tied to Project-Admins and its members, I do not think Phabricator supports to let anybody create projects with icon+color X+Y (blue components) but not with A+B (yellow tags).
If I understand you correctly.

I would still keep our simple process to request Project-Admins permissions. Requesting this once by posting in a task is not a big deal, and assures one common checkpoint in the whole project creation process.

One problem with the current instructions is that everybody must read almost everything when actually the big majority go after the simplest use cases (create a default/component type of project, or a milestone/subproject). The structure of the instructions after we agree on the changes could be as simple as

1. If you want to create a new project, you need a special permission which is easy to get (steps).
2. Once you have permissions, you can create any of these types of projects/subprojects/milestones right away. Just follow the icon/color convention (list of projects)
3. If you want to create a new tag, that requires a community sanity check (steps).
4. If you want to create a new private space, that must be done by an admin and the process for this is heavier (steps).

That makes sense, but regarding #1: Does that mean we hand out permissions to everybody and anybody who wants a new project and added their comment to T706 or (whatever venue we prefer for that)?
I'd be fine with trying that (as we can always revoke permissions), also to avoid bottlenecks.

In T139210#2630745, @Aklapper wrote:

Regarding the permissions tied to Project-Admins and its members, I do not think Phabricator supports to let anybody create projects with icon+color X+Y (blue components) but not with A+B (yellow tags).
If I understand you correctly.

We could make forms which have the values hard-coded and make those forms available to everyone. It would require making several forms but it would maintain consistency.

In T139210#2632519, @Aklapper wrote:

That makes sense, but regarding #1: Does that mean we hand out permissions to everybody and anybody who wants a new project and added their comment to T706 or (whatever venue we prefer for that)?

I'd say so too, yes.

Here is an example form: Create Component Project

I like that!

With the changes that we are looking at for project creation policy, I think we should consider generalizing the project-admins group - what we need is a Trusted-Contributors or Trusted-Contributors project which conveys access to things like: creating/editing projects, creating/editing pastes, advanced forms, owners, etc.

I've proposed these changes on a new task: T145832: Create Trusted Contributors project?

Feedback please (did I forget anything?):

• Draft of revised mw:Phabricator/Creating_and_renaming_projects in mw:User:AKlapper_(WMF)/T139210
  • No more logging in T103700.
  • Only Tag and ACL projects need prior discussion.
  • Sprint superseded by Subproject.
  • Release superseded by Milestone.
• Replace/supersede c:File:Phabricator_project_labels_5.png by c:File:Phabricator_project_labels_6.png
• If we agree on this I'm going to edit https://www.mediawiki.org/wiki/Phabricator/Project_management#Types_of_Projects accordingly.
• T145832: Create Trusted Contributors project? to handle in a separate step/task.

Just one minor point (I think): I consider Sprint to be superseded by Milestone, not Subproject. The way it is shown in the labels_6 png seems fine.

@ksmith: Thanks for the quick review!
I assume you refer to my previois comment here in Phab? Alright so, mistake on my side. :) (as I don't see anything mentioned in https://www.mediawiki.org/wiki/User:AKlapper_(WMF)/T139210 and as on-wiki docs will link to https://www.mediawiki.org/wiki/Phabricator/Project_management#Parent_Projects.2C_Sub-projects_and_Milestones anyway which is the canonical place to decide what to use for which purpose.)

I assume you refer to my previois comment here in Phab?

Yup, just in your phab comment, as far as I know.

Alright:

• Updated (diff) mw:Phabricator/Creating_and_renaming_projects as outlined in this task.
  • Also commented outdated videos.
  • Also replaced "multiple words must be connected" by "multiple words should be connected" as that is the reality (and there's now project name typeahead proposals in comments). Which also obsoletes T911.
• Updated (diff) project type descriptions (and small other bits): mw:Phabricator/Project_management#Types_of_Projects

I think we're fine for the time being and this can be closed as resolved?

Happy to fix / discuss any minor issues; happy to discuss bigger related issues in dedicated tasks.

I think it still makes sense to have release type projects, for example MediaWiki-backport-deployments

@mmodell: I hope I didn't make it sound like there should not be any release type projects at all anymore - if you can think of a better word/wording than "deprecated" please tell (or just go ahead and edit; I can always update the "project types" image later).

Probably also needs some on-wiki guidance when to go for a release type project and when to go for a milestone? (Maybe Team-Practices can help with that?)