Phabricator does not offer a list of existing projects/keywords/whatever-you-want-to-call-it to users who file a ticket; currently only type-ahead guessing so triagers would have way more work categorizing/tagging new tickets.
Upstream ticket: https://secure.phabricator.com/T1906
Related:
| Title | Reference | Author | Source Branch | Dest Branch | |
|---|---|---|---|---|---|
| maintain-kubeusers: bump to 0.0.148-20240612113501-fa8bd88a | repos/cloud/toolforge/toolforge-deploy!326 | project_1317_bot_df3177307bed93c3f34e421e26c86e38 | bump_maintain-kubeusers | main | |
| Draft: [BREAKING CHANGE] ReferenceResolver.dereference: Use new RestAPI instead of ActionAPI | repos/abstract-wiki/wikifunctions/function-orchestrator!173 | jforrester | T274269 | main | |
| maintain_kubeusers: add support for kyverno policies | repos/cloud/toolforge/maintain-kubeusers!18 | aborrero | arturo-25-maintain_kubeusers-a | main | |
| components: add kyverno | repos/cloud/toolforge/toolforge-deploy!238 | aborrero | arturo-2373-components-add-kyv | main | |
| deploy: Fix git-lfs support (submodules) | repos/releng/scap!226 | dancy | master-Id6607a5b8dea1a56b0fd0abf543ff14adafaf63d | master | |
| deploy: Fix git-lfs support | repos/releng/scap!223 | dancy | master-I3d0dd46a4cffe6c89c1d9652ad0575587e267bc9 | master | |
| Update function-schemata sub-module to HEAD (9c74b2c) | repos/abstract-wiki/wikifunctions/function-evaluator!144 | jforrester | sync-function-schemata | main | |
| Update function-schemata sub-module to HEAD (9c74b2c) | repos/abstract-wiki/wikifunctions/wikilambda-cli!27 | jforrester | sync-function-schemata | main | |
| Update function-schemata sub-module to HEAD (9c74b2c) | repos/abstract-wiki/wikifunctions/function-orchestrator!124 | jforrester | sync-function-schemata | main | |
| tests: Replace almost all non-standard ZIDs with test range (Z4xx) | repos/abstract-wiki/wikifunctions/function-schemata!76 | jforrester | T278596 | main | |
| Add Dynamic List of languages from i18n directory | cloudvps-repos/videocuttool/VideoCutTool!22 | varun-s22 | add-dyanmic-list-of-language | master | |
| Remove unused Sprint submodule | repos/phabricator/deployment!29 | aklapper | rmSprintSubmoduleT275325 | wmf/stable | |
| fab: build images with user dockerpkg-builder | repos/releng/dev-images!39 | hashar | fab-shared-user | main | |
| make-release: Stop branching GWToolset | repos/releng/release!31 | jforrester | drop-gwtoolset | main | |
| make-release: Drop Renameuser, now in core | repos/releng/release!14 | jforrester | T27482 | main | |
| Update buster-based images to composer 2.1.8 | repos/releng/dev-images!7 | jforrester | composer-2 | main |
qgil wrote on 2014-04-07 18:12:14 (UTC)
Typing ahead is probably the sane approach when you know where you want to file a bug. It is also better than a list of projects in a context of hundreds of projects (our case, if every MediaWiki extension deserves a project). Most users have a sense of which piece of software they think a problem is related to, even if the choice is wrong.
For the reports needing to look through a list of projects, Phabricator does provide a list of all projects, but it looks like it is not possible to add descriptions or some structure? Should we offer a comprehensive list, edited manually?
Another question we should ask is who knows enough to land in Phabricator, but not enough to know which project to choose. Where did they come from? What link did they follow?
Is it possible to point to a URL to create a task, with a project already pre-filled, akin to https://bugzilla.wikimedia.org/enter_bug.cgi?product=Analytics ? We could use these links in the wiki pages of the most popular projects, the ones that most likely will attract most new reporters: top key Wikimedia projects, Beta Features, extensions...
aklapper wrote on 2014-04-09 14:39:57 (UTC)
Second part (URL parameters to specify project) split into T60.
aklapper wrote on 2014-04-09 14:40:23 (UTC)
I wasn't aware of http://fab.wmflabs.org/project/query/RyA8ZHCM4BnN/#R - thanks for finding out!
qgil wrote on 2014-04-18 17:08:07 (UTC)
After filing my first task in Phabricator upstream I can only say that type-ahead worked a lot better than any dropdown menu or documentation page. Definitely better than trying to find the right Product+Component in Bugzilla:
Applications with Public permissions requiring users to login
https://secure.phabricator.com/T4830
In Projects, I typed: "app...", "perm...", and then the beginning of each project name. There was always a suggestion that I could simply select. I had absolutely no idea about the list of projects in https://secure.phabricator.com/ and, to be honest, I still don't know and don't care as long as I find sensible results whenever I file a bug.
Therefore, I would resolve this task as WONTFIX. We don't want to show our users "projects list when creating new task in Maniphest". What we need to do is our homework at T68, in order to offer our users the results they expect when filing a task.
Nemo_bis wrote on 2014-04-18 17:10:58 (UTC)
Possible. But we're in the wikipmediawiki world...
qgil wrote on 2014-04-22 18:06:35 (UTC)
What do you mean?
In any case, type-ahead is a good solution. We can wait for upstream to resolve https://secure.phabricator.com/T1906 and then decide what to do with it. In the meantie, this doesn't look like a blocker for the RfQ.
aklapper wrote on 2014-04-23 06:34:58 (UTC)
I am a little bit concerned that users won't find their way to the right project and that it'll take longer until a developer sees a bug report in her/his basket due to required triaging by adding the corresponding project(s), but maybe I'm just overpessimistic, so let's see.
qgil wrote on 2014-04-23 14:43:46 (UTC)
To me the problem boils down to have a collection of projects with labels that make sense, knowing that some of those projects will act as funnels for tasks that probably belong elsewhere e.g. "MediaWiki" or "en.wikipedia.org". The good thing is that we could enroll tech ambassadors & co to help there. Something to be discussed at T68: Watch a user (via Phabricator's Herald).
Good things that Phabricator has:
We could even restrict the possibility to change priority to members of a Prioritizers project that anybody could join, forcing "Needs Triage" as default for newcomers and casual users. We can also discuss this at T68.
Nemo_bis wrote on 2014-05-07 10:35:31 (UTC)
Hesitant users can create a task without assigning it to a project. It is easy for bug triagers to track orphan tasks.
General/Unknown is already used for this.
qgil wrote on 2014-05-07 15:56:12 (UTC)
In Phabricator users can just leave the Project field empty. In Bugzilla they can't. They still must choose a product and find the General/Unknown component there.
In Phabricator there is only one pocket for tasks that haven't been assigned to any project. We could even create an "Orphan tasks" project and a rule to assign there all the tasks that were filed without a project. In Bugzilla you have several pockets, which makes the scanning more complex.
By now I have filed dozens of reports upstream, being a new user in that community that has used Phabricator during a few week only, finding always relevant projects by typing ahead. Changing priority to Wishlist until it is proven that the current behavior is indeed problematic.
aklapper wrote on 2014-06-11 16:00:56 (UTC)
For the records, simpler query to get a list of projects might be http://fab.wmflabs.org/project/query/all/
aklapper wrote on 2014-06-17 21:21:29 (UTC)
Related, and likely way easier to implement than this ticket: T425
I wonder how the UI is supposed to work with hundreds of projects... For reference, https://bugzilla.wikimedia.org/describecomponents.cgi has 34 entries, and I bet most users don't even scan half of it.