Page MenuHomePhabricator

Projects shouldn't allow setting "joinable by" to itself
Closed, WontfixPublic


Setting a projects joinable field to itself is equivalent, and less intuitive, to setting it to "No One" so projects should enforce that.

Event Timeline

jdloft raised the priority of this task from to Needs Triage.
jdloft updated the task description. (Show Details)
jdloft added a project: Projects.
jdloft added a subscriber: jdloft.

It is very difficult, if not impossible, to determine if a policy actually means 'no one'. Other ways for this to happen is to set 'joinable by' only to disabled users, to set two projects to be joinable by each other, etc.

It is very difficult, if not impossible, to determine if a policy actually means 'no one'. Other ways for this to happen is to set 'joinable by' only to disabled users, to set two projects to be joinable by each other, etc.

I'm not sure I understand you fully but its already possible to set a project's joinable field to no one (as demonstrated by my test project). We set this so a project is essentially invitation only. Users can only be added through the members menu by joined users.

jdloft renamed this task from Projects shouldn't allow setting "Joinable by" to itself to Projects shouldn't allow setting "joinable by" to itself.Jul 6 2015, 2:22 AM
jdloft updated the task description. (Show Details)

My point is that just preventing a project from being set to joinable by itself is insufficient. There are other ways to effectively set a project to "joinable by no one" without using the no one policy.

Both are equally non-intuitive. Is there a specific problem you are having using Phabricator?

epriestley claimed this task.
epriestley added a subscriber: epriestley.

Generally, we prefer UI consistency and a simpler UI ruleset over preventing users from doing silly things.

An example is that you can "Send Message" to yourself from your profile. This option isn't very useful, but it's consistent and makes the interface more predictable.

Some of the problems with trying to prevent users from doing silly things include:

  • When we remove options without explanation, this is potentially much more confusing if a user expects the option to exist but it does not, and there's no hint or explanation as to why. The rule ("You can't set a project's policy to itself", "you can't message yourself") may be intuitive to us in context, but often isn't intuitive to a new user out of context. Giving users UIs that are confusing and offer no path forward is bad for them and increases our support burden, so this approach is generally off the table.
  • So the minimum level of UI affordance is normally to either disable options with an explanation, or warn users about selecting "silly" options. For example, in this case, we might grey out the project name (but still show it as an option) and pop up a dialog when you try to select it. This fixes the "total confusion / no path forward" scenario that users can encounter if we simply remove the option, by letting them select the option and then learn the rule which disables it. However, this is often a lot of complexity for a very questionable benefit. In this case, it's not clear to me that preventing users from selecting this policy and telling them to select a different, equivalent policy would actually make the interface better: it seems like a lot of work for us and for the user to achieve the same result.
  • We may not be able to guess which things are "merely silly" vs "silly and completely useless". For example, using "Send Message" on yourself can be useful for testing/development. Users might use it to write notes to themselves. Users might think this way of expressing "joinable by" is more clear. In all of these cases, the utility is probably very marginal, but it's hard to be sure that there's zero utility in an option. Since we're often talking about removing options which work correctly, are consistent, and obey all the UI rules, it's not like we're removing broken options: they work fine, and in some cases users do use them for something. So we can harm real use cases by mandating that certain options are too silly to exist.

Of course, there's a balance here. For example, if users are frequently having trouble accurately expressing intent in a UI, that suggests we should change things, and removing "silly" options might be one approach. However, that's the root issue we'd want to tackle, and this report doesn't suggest that the UI is actually confusing, just that it doesn't force policies to be specified in minimal form. We don't require this, and can't realistically require this: there are infinite policies that evaluate to "no one", and some are almost certainly more intuitive in some contexts than "No One" is.

When the root of a problem is "it is possible to do something silly", but that silly thing is consistent, works in an intuitive way, allowing it gives us a simpler ruleset, and the silly thing doesn't cause harm on its own, we'll almost always allow the silly thing. Disallowing the silly thing makes the code more complex, makes the UI more complex, often does little practical good, and may harm off-label use cases.

Finally, here's a goofy scenario where this setting might be useful and desirable:

  • You have a project called "People who can Join Projects".
  • You set the default join policy for new projects to "Members of People who can Join Projects".
  • If you set the project join policy to itself, the policy hint will show grey ("standard policy") in the header.
  • If you set the project join policy to "No One", the policy hint will show red ("more restrictive policy") in the header, which has the same effect but is arguably less intuitive because it's actually the standard policy.