Topic on Talk:Phabricator/Help

projects/tags/hashtags/etc. (synonymous with eachother?) are AIUI sometimes used as ACLs, sometimes used as task categories (a la bugzilla component), and probably in other ways I'm forgetting.

some tasks are in no project at all. e.g. phab:T599. should that be avoided?

some tasks are public but have projects that have restricted access. e.g. phab:project/view/29/ AFAIK, the only way to subscribe to/watch a project is to first join that project. that project says:

This group should reflect the 'ops' group in admin.yaml.

This group is also used for permission-y type things in places, please don't add folks who are not part of operations.

maybe we should have a policy that any project which has tasks defaulting to open viewing/editing should not also be used as an ACL. if teams need an ACL then they can have a separate dedicated project to be used as ACL and nothing else. are there existing projects that have duplicates like that? one for team membership/CC list/etc. and a separate one for ACL usage. if we do this then we should have a new color coding, symbol, etc. to mean "ACL". still I would worry about people accidentally choosing the wrong (too-broad) project among a pair of projects. (or not noticing that someone else chose the wrong one)

or fix phab to allow non-members to be watchers.

Generally, "no project at all" should be avoided and needs triage - it's similar to reporters creating tickets under "General/Unknown" components in Bugzilla. It sounds like the problem boils down to following tasks that traditionally are/were handled in RT? I don't exactly know or could judge how "open" or "accessible" tickets in RT are to anybody interested so I don't feel entirely comfortable to comfort on potential best practices yet. :-/

No, this has nothing to do with RT. phab:project/view/30/ is equally problematic.

Most users can't join the project but some tasks are in that project. No way to watch all tasks in that project without joining. (or maybe making your own personal herald rules? oh, wait, no herald!)

The current behavior of private tasks / projects is not final, see T517 Still, restricting access to tasks based on project membership and T716 security extension doesn't need to strip out projects of newly created tickets (only add security).

I'm not entirely sure why I need to join a project to be able to follow the team's activity on Phabricator ("watch"). I just want to learn about the bugs, I don't want people to think I'm a real member of that team when I'm not. Am I missing something?

Maybe the "Members" term is slightly misleading here and should be "Members and/or Subscribers" in our usecase.

This has been fixed, projects can now have subscribers separate from members.

Yes, currently we have a bit of a mess in the project policies, in many cases because it is not well understood what those policies actually do (i.e. NOT restricting access to tasks). Let's nail down this at T705 and Phabricator/Requesting a new project#Policy.

About tasks without projects, the ones I'm seeing are tasks that genuinely lack a project because we are limiting project creation. This will change as soon as T705 is solved. After the Bugzilla migration, the real triagers will help assigning orphan tasks to projects.