Main page for the tool itself: https://www.mediawiki.org/wiki/Phabricator/Help with subpages for application specific-information, like https://www.mediawiki.org/wiki/Phabricator/Help/Legalpad
(Please feel free to edit this initial description by adding more links.)
Related links:
* https://www.mediawiki.org/wiki/Bug_management and subpages, e.g.
* https://www.mediawiki.org/wiki/How_to_report_a_bug
* https://www.mediawiki.org/wiki/Bugzilla and subpages, e.g.
* https://www.mediawiki.org/wiki/Bugzilla/Fields
* https://en.wikipedia.org/wiki/Wikipedia:Bug_reports_and_feature_requests
* https://wikimediafoundation.org/wiki/Bugzilla_administrator_rights_policy
* https://www.mediawiki.org/wiki/Annoying_little_bugs
* https://www.mediawiki.org/wiki/Backporting_fixes based on T167
* ...
Stuff that might be worth to cover:
* T46 / T127/T172: Setting up notification rules (e.g. "get all notifications for tasks filed under project XY", "following activity of a person") in http://fab.wmflabs.org/herald/
* T153 comment 18: Querying relative timespans (e.g. "tasks created in last 24 hours")
* adding other approved auth providers: http://fab.wmflabs.org/settings/panel/external/ (cf. T338)
* how to find tasks that I filed: http://fab.wmflabs.org/T418#4
* do not get mail notifications about my own actions: settings/panel/emailpreferences/ → Self Actions (cf. T135)
* Document the difference between projects and tracking/dependency tasks. This differentiation was never clearly made in Bugzilla, mixing up tracking bugs (tracking tracking bug 2007 plus duplication via "tracking" keyword) and keywords: Projects should be "items that can //never// be considered fixed", e.g. Bugzilla bug 1 "Improve our documentation". Bug reports that //can// be declared fixed at some point with dependent (sub-)tasks should become tasks instead.
* If we don't implement T425 for Day 1 (I doubt), document to leave the project field empty when filing a new task and not being sure
* Make clear that adding a token does not subscribe you to a task, but that you should add yourself to the CC list instead (cf. T150)
* Document that (search query) URLs can be shared: T398
* Project creation: Document that people (well, admins) creating projects in Phabricator should set //Project visibility// to //Public// by default. Only if there are very good reasons (Security project, cf. T95) restrict access. Nemo_bis found this problem in T397.
* Project creation: The //naming scheme// must be clearly documented (cf. T68) otherwise we end up in a complete mess as we try to turn lots of different things into projects. Chase might be also interested in it.
* If drag and drop for upload does not work, use /file/upload/ and refer to the file by using F123 markup (cf. T271). Users can also copy and paste images via the clipboard functionality. Advanced users could also use "arc upload" which provides an F number that can be used via {Fxx} syntax to embed in a comment.
* File permissions: Note that you cannot upload a file and then decrease the access level to the file (e.g linking it to a security ticket). You would have to delete the file and reupload it with stricter access permissions. It is recommended to upload files which should have restricting access together with the creation of a restricted (security) ticket.
* As long as T52 isn't fixed: To get an overview list of projects, go to http://fab.wmflabs.org/project/query/all/
* Recommend to paste full URLs from the address bar of your web browser, instead of wiki markup like "[[:mw:Talk:Flow]]" which is not supported (cf. T100)
* Provide some ''common'' queries, such as how to view list of latest filed tickets
* For devs/maintainers who'd like to provide direct links (e.g. on a wikipage) to create a new Maniphest task about their project, see https://secure.phabricator.com/T3320 for available parameters to pass in an URL: projects, title, description, assign
* Cover how you are supposed to "claim" your account in Phabricator, to e.g. be able to query for tickets that you had filed in Bugzilla?
* ...