Phabricator/Creating and renaming projects

New projects
Any member of the Project-Creators group can create new projects. To either request or to document the creation of a new project (see section below), [ create a new task] under Project-Creators including these details:


 * Name
 * Description
 * Type of project
 * Policy (only if different from the default)

See Phabricator/Projects for a list of existing projects.

Phabricator is a public place. In order to keep some sanity and consistency, new tags and private projects must [ be proposed and discussed before being created]. Any other project types (except for sprints and releases) must be documented [ by creating a dedicated task in the project "Project-Creators"]. This is true for everybody, project creators included. There is no formal decision process; common sense prevails. After someone has created the project, the person changes the status of the dedicated task to "resolved".

If a project is missing quality requirements or found problematic, a task can be created assigned to the creator of the project, describing what is missing. The project could be archived until its situation is clarified.

Name

 * Think of the shortest name that users can find easily typing ahead.
 * Ideally one word, otherwise multiple words must be connected with dashes in order to allow linking project names in the context of Phabricator's markup (cf. T43).
 * Unnecessary use of frequent words like "Wikimedia" or "MediaWiki" should be avoided, except for differentiation to help avoiding misunderstandings (e.g. WMF-Design for a Wikimedia Foundation team project, in contrast to general design issues)
 * Sentence case or CamelCase by default.

Good: Phabricator, MediaViewer, MediaWiki-Special-pages...

Bad: Wikimedia Phabricator, MediaViewer-for-MediaWiki, Code Review for Phabricator...

Description

 * Describe the project in a way a newcomer would understand it.
 * Add links to the relevant project pages.
 * Subprojects should link to their Phabricator parent project.

Type of project


There are several types of projects in Wikimedia Phabricator, and each type must follow the purpose, color, and icon defined in these guidelines.


 * Component is the default option. A component corresponds to a distinct and recognizable piece of software/service. Creation must [ be documented]. Icon+Color: Briefcase+Blue.
 * Team corresponds to an existing team. If you belong to a team that will manage several projects, then the first step is to create a project for your team. Creation must [ be documented]. Team projects can be automatically added to (sub)component tasks by requesting a global Herald rule. Icon+Color: Team+Violet.
 * Sprint is for subprojects of a team being worked on in a certain timeframe. Specify the start and end dates when requesting creation of a new Sprint project. Icon+Color: Deadline+Green.
 * Release is for subprojects that belong to a specific deployment defined by a date or a (future) software version. Icon+Color: Release+Orange.
 * Goal can be used for projects without a defined ending date but which can be definitely realistically be defined as finished at some point. Creation must [ be documented]. Icon+Color: Goal+Orange.
 * Tag is used as a cross-component keyword (like "accessibility"). Tags must [ be proposed and discussed before being created]. Icon+Color: Tag+Yellow
 * Private / ACL projects enforce policy restrictions to not unnecessarily restricted Team project membership and to allow any people to join and watch such Team projects. Creation must [ be proposed and discussed before being created]. See T90491. Icon+Color: Policy+Red.
 * Personal per-user projects allow to track progress of personal tasks. They currently are a test only, see T555. Creation must [ be documented]. Icon+Color: Accounting+Checkered.
 * Umbrella projects can be used for larger projects that do not have a distinct code base and that consist of several (sub)components. Umbrella projects can be automatically added to (sub)component tasks by requesting a global Herald rule. Creation must [ be documented]. Icon+Color: Umbrella+Blue.
 * The special Patch-To-Review project is automatically added to a task when a related patch in Gerrit links to that task.

Additional hashtags
Hashtags are used to link to projects in descriptions and comments, as well as to call them in searches typing ahead.


 * Optional field, you can leave it empty.
 * Or you can add shorter / alternative tags that clearly identify with your project.

Good:  for Affiliations-Committee.

Bad: acronyms nobody will guess, misleading tags...

Policy
IMPORTANT: this policy applies to the project page itself, not to the tasks assigned to a project!

Default policy
The default access policies for Wikimedia Phabricator projects should be set to:
 * Visible To Public (no login required)
 * Editable By All Users
 * Joinable By All Users

This corresponds to the policies of wiki pages of teams, projects, extensions, etc, in mediawiki.org. Just like there is no reason to protect project wiki pages by default, there is no reason to protect Phabricator project pages by default.

Restricting Visible To
There should be no reason to restrict the visibility of a project page. All Wikimedia Phabricator projects should be Visible To Public (no login required).

Restricting Editable By
Similarly to wiki pages, protecting project pages from being edited by All Users should be an exceptional measure to prevent or respond to abuse.

Restricting Joinable By
This is an option to be used mainly for Team projects where membership provides special access to features. If you want to restrict this option you need to justify this decision in your request.

Note that Phabricator allows to subscribe and watch projects only to their members. If you want more users following your activity, you should let them join the projects. If you want to define who is an official member of your team, you can do so editing the project description.

Renaming projects
By default, all users can rename a project. The requirements are project consensus (obviously, and the Phabricator maintainers will not check that you got it) and compliance with the guidelines listed below on this page.

Renaming a project is similar to renaming a wiki page. You need to make sure that you are not leaving broken links after the change of name.


 * Make sure the current hashtag is kept as an additional hashtag. Otherwise, the references to your project that people added in comments and descriptions will break.
 * Phabricator will not allow you to rename the project and add the current hashtag in a single step. You must first rename and then add the hashtag.
 * Remember to update the links in your project pages and templates. For instance, extension projects need to update their infobox.

Something to consider if you project has a volatile name: use URLs with the project number in wiki pages and other external resources. This saves you problems when the project is renamed, since the project number stays the same.

https://phabricator.wikimedia.org/project/board/5/ vs https://phabricator.wikimedia.org/tag/phabricator/ https://phabricator.wikimedia.org/project/profile/5/ for the project description page of the Phabricator project