You can remove "Test Plan" by disabling the field in differential.fields in Config.

In general, it would be helpful to have a specific list of changes you want to make and the reasoning for those changes.

For example, with the "Subscribers" field, there are many possible ways it could be disabled:

• disable the ability to subscribe to objects completely, across all applications;
• disable the ability to subscribe to revisions completely (but retain it in other applications);
• retain subscriptions, but make it impossible to interact with them from the CLI;
• retain subscriptions, but don't write them to published commit messages (in the vein of T7443 and T2920);
• retain subscriptions, but never write them to commit messages shown to the user at any stage of the pipeline;
• retain subscriptions, but don't offer them as a default empty field on the template.

From your description, it isn't clear which of these you want. Other users may want different things, so if we add a single checkbox to do one of these behaviors it's probably a poor fit in the general case.

The "JIRA Issues" field only appears if you have JIRA configured. In this case, it would be helpful to understand why you want JIRA integration but don't want the field.

See also T6030, T10620, and broader tasks T10329, T11429.

Overall, I'm not sure what the root problem here is, e.g. it doesn't seem like having a "Subscribers:" field on the template hurts anything, even if it isn't used very often.

Thanks Evan.

To clarify, we actually do use the JIRA Issues field ourselves, but while filing this ticket, I figured other organizations might not use it, so I used it as an example of a field someone might want the option of cleaning up. For our own specific usecase, the only field I'd like to hide is the Subscribers field. The desired functionality is probably:

retain subscriptions, but don't offer them as a default empty field on the template.

My reasoning is that subscribing seems like something that the *subscriber* would initiate, and most likely is done via the web interface. If the author of the diff wanted to add a subscriber at diff creation time to keep them in the loop so that person keeps getting notifications, adding them as a Reviewer achieves the same purpose. As an author, adding a subscriber post creation of the diff via the web interface is easy enough, too.

adding them as a Reviewer achieves the same purpose

These are separate fields because they can have slightly different meanings: revisions appear on different dashboards depending on whether the viewer is a "Reviewer" or "Subscriber". In particular, a revision does not appear under your "Responsible Users: epriestley" default dashboard if you are just subscribed to it.

More broadly, the fields can also be used to indicate different intent. For example, if someone ("alice") reports a bug to me, I may fix it with a revision like this:

Reviewers: chad
Subscribers: alice

..meaning "alice, here's the fix for that bug we talked about, but I want chad to actually review it because it's modifying an area of the codebase that you aren't familiar with". I don't do this super frequently, but do it often enough that I find the "Subscribers" field useful.

It's possible that you never use these fields differently, and that no one at your organization does or ever will, but that's the reasoning for them being separate, at least. We haven't seen other requests to hide this field by default, and there's a reason that it's visible, and the cost appears to be very small, so I don't specifically plan to hide this outside of the scope of larger issues (like T6030) which may end up making this more globally configurable.

I'm just going to merge this into T6030, which I think is the most similar open task.