You're required to verify bugs at HEAD. Please update your install.

T6183 and T6113 are the relevant tasks I was able to dig up. Sounds like that option should just get removed?

This isn't the same as T6183 or T6113, and isn't expected.

"Watching" a project sends you email about every task, revision, etc., that gets tagged with the project. This is an enormous volume of email on an active install, and equates to automatically subscribing to hundreds or thousands of objects.

"Subscribing" to a project sends you email about the project itself (name changes, description changes, etc).

Oh, by "remove the option" I meant "remove the option to subscribe to a project if you are not a member of the project" -- that is, "Subscribe" is disabled if you aren't a project member. I don't currently plan to remove the option, although I am leaning towards making members not be subscribed by default.

I don't currently plan to remove the option

Sorry, this time I meant "I don't plan to remove the option to subscribe to a project (provided you are a member)".

For the sake of completeness, the root issue you described elsewhere (unsubscribes cascading into more unsubscribes) is fixed (at least, indirectly) at HEAD, after 536d3a2, which stops self-subscribes and self-unsubscribes from publishing feed stories, mail, and notifications.

Overall, the problems I currently see with watch/subscribe are:

• not being able to watch anything is confusing (T6183);
• not being able to subscribe to anything (like you can in other applications) is confusing;
• the distinction between the two is confusing (T6113); and
• subscribing to projects is rarely useful anyway (membership changes, description changes, etc., are mostly uninteresting).

These problems tend to make one another worse. For example, users who want to watch projects sometimes join them so they can, which causes them to subscribe to them, which they don't necessarily want. This would be avoided if you didn't need to join to watch.

Some changes have already improved these issues:

• Historically, the "you must join" requirement for both watching and subscribing was largely a protection against limitations in the policy system, which have since been fixed.
• D14853 dropped the lowest-value mail about subscribes/unsubscribes.

However, I anticipate subprojects also making these issues worse by making the landscape more complex, if nothing else. They may also introduce more interesting types of transactions (for example, deadline changes on milestones) which might motivate subscribing more strongly.

I anticipate making these changes:

• Allow anyone who can see a project to watch it.
• Allow anyone who can see a project to subscribe to it.
• Probably stop autosubscribing on join, unless subprojects/milestones add very interesting transactions.
• Probably keep autosubscribing the creator?
• If subprojects do create higher-value transactions, maybe monkey around with other very-low-value transactions (join/leave)?

Anyway, thanks for the report. This should be fixed in HEAD.