0000-template.md: Encourage discussion of maintenance

[joshtriplett]

Add some points to encourage RFCs to discuss how a proposal impacts the
ease of reading, understanding, and maintaining Rust code, not just the
ease of writing it.

Inspired by many recent discussions on proposed language features.

cc @rust-lang/lang

[mgeisler]

Thanks, I think this is a great addition.

[Centril]

This does not constitute a change in policy right, just a reminder to authors?

The changes in the text look super great to me 💯.

[joshtriplett]

@Centril I don't think this is a change to policy, no, just some encouragement to cover this point in RFC text.

[WiSaGaN]

I think one of related points is to invite more industrial users to voice their opinion and concern. They are the main proponents for language adoption, and they have more experience in using the language in production.

[burdges]

Just a fun quotes from Yaron Minsky's Effective ML talk:
"Whenever there is a difference of opinion between [the writer of code and the reader of code], the readers are always right and the writers are always wrong." -

I'm not criticizing recent ergonomics features here, like default binding modes might make auditing the logic's correctness easier. I just like the sentiment overall. :) In fact, another couple fun quotes from his Caml Trading talk:
"You basically cannot pay people enough to code review dull [boiler plate] code. .. We've tried."
"Any [mental tools] that let you offload [the informal proofs involved in reading code] is a huge win"

[nikomatsakis]

I'm a bit concerned that the templates are becoming a kind of laundry list. I'm a bit concerned because complex templates are a bit of a barrier to entry and often don't apply to all teams (e.g., does this apply to a "policy RFC"?).

Furthermore, people can simply delete these points, and then it's as if they never existed — when really what we want is to ensure that the discussion takes these points into account.

I have an alternate proposal. Instead of putting this text in the template, where it can be deleted or overwhelming, maybe we should make a "review-guidelines" directory on the repository with "per team" advice. So e.g. the lang team could include this (and other) considerations. We can then add advice encouraging reviewers -- both team members and non-team members alike -- review the RFC with respect to these criteria (in addition to their general thoughts).

[joshtriplett]

@nikomatsakis I can absolutely agree that an excessively busy template could do as much harm as good. I would certainly be happy to edit the templates in more detail, and perhaps attempt to streamline them somewhat in ways that reflect how people tend to describe proposed changes in practice.

However, I do think part of this change ("Does the proposed change make Rust code easier or harder to read, understand, and maintain?") applies to any kind of change, library and language alike. The "If this is a language change" bit is perhaps more awkward. I think I could find a way to make it fit better, though.

Does that seem plausible?

[matu3ba]

@nikomatsakis Any progress on this?
Identify the different subtypes would be a start. Do there exists efforts on that?

Bot-processing could also be used.

Ideally the status would be labeled as well (experiments, abandoned, active) with a infrequent ping for update status of the author(when no discussion takes place).

[nikomatsakis]

I had completely forgotten about this. I don't really have a strong opinion one way or the other I suppose. =)

[lahwran]

I would vote to merge. I think this change applies well to itself.