Page MenuHomePhabricator

Allow adding a herald rule based on a phriction document author's projects
Closed, DuplicatePublic


We'd like to be able to automatically send an email whenever users of a certain project ("new wiki editors") make changes. Currently the herald rules only permit specific authors rather than the author's projects

There are two problems we'd like to solve:

  • new users are sometimes clueless, spammers, or otherwise unhelpful when making changes. Instead of requiring users to subscribe to every page that a new user might edit or stalk there changes it would be helpful to be able to watch them for a little bit.

An alternative to this approach would be to require certain users get their changes pre-approved but that seems much more heavy handed.

  • Certain pages are "risky content": for example describing security configuration. We'd like to be able to subscribe to changes by non-security team members (rather than any change)

Event Timeline

eadler raised the priority of this task from to Needs Triage.
eadler updated the task description. (Show Details)
eadler added projects: Herald, Phriction.
eadler added a project: FreeBSD.
eadler moved this task from Backlog to Nice To Have on the FreeBSD board.
eadler added a subscriber: eadler.

I updated the task description hopefully better describing the problem

@eadler the main problem with filing feature request solutions, then trying to justify it with problems is it makes our job significantly harder, that we have to reject multiple things or try to formulate long reasoned answers for each item. When you just file a problem, we're much more easily able to manage and group it with other (similar) problems. The solutions might change, but we're a very small team and when we solve problems, we try to group them to satisfy the most use cases. Just trust us with your problems.

(Reviewing Wiki Pages seems reasonable at some point).

We also talked about forcing people to use 'story cards' for requests. So it'd be something like:

"As a <role>, I want <goal/desire> so that <benefit>"

Maybe our documentation could be improved?

See T7962 and T8054 for previous requests to describe problems.

Is what we want (problem descriptions, not proposals of solutions) unclear?

Is why we want it unclear?

Are they both clear, it's just easy to forget when filing tasks?

Or does it seem like the instructions are for a different (e.g., less technical) audience, and is it unclear that we intend them to apply to technical users too?

I think Are they both clear, it's just easy to forget when filing tasks? sums it up the best: I am primarily used to other projects and other trackers. Another issue is that sometimes I'll "fast forward" my thoughts: have a problem, think through the solution, and then forget to describe the problem.

I'll try chad's approach of using a story based approach next time.