Page MenuHomePhabricator

Let non-members watch projects
Closed, ResolvedPublic

Assigned To
Authored By
GWicke
Dec 8 2014, 4:42 PM
Referenced Files
None
Tokens
"Love" token, awarded by Base."Like" token, awarded by Kozuch."Evil Spooky Haunted Tree" token, awarded by Nemo_bis."Love" token, awarded by fbstj.

Description

Reported upstream: https://secure.phabricator.com/T6183

I noticed that the 'watch' feature (receive notifications on all activity in a project) is currently only available to members of the project. We'd like to use this feature to invite outsiders to follow along, even if they aren't members of the project.

Is this

  1. possible in phabricator, and
  2. could we enable this?

The same limitation seems to hold currently for 'subscribe' as discussed in https://secure.phabricator.com/T6113.

Event Timeline

GWicke raised the priority of this task from to Needs Triage.
GWicke updated the task description. (Show Details)
GWicke changed Security from none to None.
GWicke added a project: Phabricator.
GWicke updated the task description. (Show Details)
GWicke removed a subscriber: Aklapper.
GWicke subscribed.
Qgil triaged this task as Lowest priority.Dec 8 2014, 6:16 PM
Qgil edited projects, added Phabricator (Upstream); removed Phabricator.

This is not possible in Phabricator today. While this is the situation, we recommend to keep the Joinable By project policy to All Users. See

https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#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.

My question is why you might not allow anybody to just join the project.

@Aklapper: We normally do, but requiring people to add themselves as members of a project (which they might not feel they are if they are just casually following it) in order to even see the option of watching / subscribing to the project is not very inviting. It also makes looking at 'members' useless for getting an idea about 'who is working on this'.

I'd like to be able to give people a link to a watch dialog as an option to follow a project / tag. We actually have very targeted tags for this purpose (restbase-architecture and restbase-api) to make sure that people can subscribe only to the aspects they are interested in. We only add those tags to topics that should be of interest to the respective audiences. This has the potential to give us a very high signal/noise ratio, and partly reduce the need for parallel mailing list discussions.

All this does not work too well though if the sign-up process is a multi-step process.

Also, for comparison: On github anybody can subscribe to a repository, and this is a frequently used feature. For example, the Rust community uses an RFC repository to design the language, and invites people to follow along by subscribing to the repository. Phabricator tags could be even better than the coarse per-repository subscriptions on github if subscription / watching was easy.

It also makes looking at 'members' useless for getting an idea about 'who is working on this'.

In terms of our usage, this is a good point to me.

This might be very helpful, for teams to be able to limit who can move items around on their workboard, but whilst still allowing any user to watch the activity of the team, with a single click.

E.g. the Collaboration Team doesn't have any tasks of its own, but primarily exists to do management of [sprint-level and quarter-level and longterm] tasks. It is currently set as restricted access to join, so that the PM/team has control over their own schedule.
IIUC, Someone not on the team could join each of the extensions that the team deals with (Flow/Echo/Thanks/WikiLove), and I think (?) they would see exactly the same email/web updates as they would if they had joined the Collaboration Team. The only difference would be an inability to move items on the Collab Team's workboard. If so, would this be a reasonable long-term setup to leave it in?

This would also occasionally (not often) be helpful for making private Pastes, that are automatically shared with the team/colleagues who are covered by appropriate NDAs.

(Sidenote: There was also a thread discussing aspects related to this, on https://lists.wikimedia.org/pipermail/teampractices/2014-December/thread.html ("Team membership, what does it mean."))

Qgil raised the priority of this task from Lowest to Medium.Dec 18 2014, 2:34 PM
Qgil updated the task description. (Show Details)

The concern here is users watching or subscribing to projects (like "Security") which they may have permission to see, but not to join. In particular, we are likely to allow subscribers to punch through policies in the future (T4411), which probably means project subscribers should get the same exception. It's very bad if anyone can subscribe to any project, and subscribing to a project means you can see anything the project is subscribed to.

A more correct way to implement the policy exception is to provide it only for project members, but that adds a level of complexity to the ruleset, where sometimes "being subscribed" matters and other times "being a member" matters.

A general future concern is that if you create, say, a Conpherence and invite some project (after T5364), we should only be inviting members, but then subscribe/watch sometimes work and sometimes don't.

I think there's no clear way forward here yet. The current ruleset give us the most flexibility going forward, and we could relax who is allowed to subscribe or watch later. It's harder to put the genie back in the bottle.

Upstream has set a blocking task: Adding a CC to a Maniphest Task should give View rights for that user

I have mirrored the dependency here, although I'm not entirely sure that this is just as symmetric.

Naively I think the current term "Members" should just be changed to something better, but not sure if the words "Followers" (instead of "Members") and "Watchers" are separate enough when it comes to express how "loosely/closely" you watch it.

@Aklapper, to make watching a feasible 'follow this topic' mechanism we need to have a way to give people a simple link to click. A multi-step process is unlikely to get many people signed up.

@GWicke, sure, @Aklapper is just trying to find a short term improvement to clarify the current situation that we can implement here trivially. Any substantial change allowing to bypass "Join project" in order to become a watcher requires an upstream solution, probably not sort term at all.

Sadly, I don't think that renaming labels will solve much. The point of confusion is still how to watch projects when you cannot join them.

Previously, you had to be a member of a project to watch the project. Now, anyone can watch a project. This doesn't let you see anything you can't otherwise see.

mmodell claimed this task.