The current wording at "Types of issues within scope" makes it sound like everyone has to get this committee's sign-off on a huge variety of changes, including potentially things like adding a new public or protected method to a class (since that's part of the "public interface" exposed to extensions). Is that really intended?
Topic on Talk:Wikimedia Technical Committee/Charter
I imagine that this kind of consultation and sign off would be required only on "major changes" (subject to judgement of people concerned) vs. every small change that affects a public interface.
I think the intention is that if reviewers are concerned with a change/commit/bug they can bring it up to the committee as it is within their scope, but they aren't going to try and review every bug/commit. I agree that this could/should be written better.
ArchCom didn't have time to discuss this today, but plan to address it later.
@Anomie I indeed expect a large variety of changes to be in scope, but not a very large number. I don't think we'll want to be asked to sign off on every new public method on any class. I'd hope that developers have a good idea of when such an addition might be hard to undo, or strategy, or cross-cutting.
Of course, such an assessment may turn out to be wrong. There is no way around that.
I see the scope definition not as a hard test that can be applied to any change. It will often be a matter of subjective assessment and common sense.
I'd be wary of defining the scope very broadly and relying on common sense to reign it in. Common sense is notoriously unreliable.
I agree that "Common sense" would be too vague, especially when applied to just "anyone" who uploads a patch. We cannot (and should not) expect contributors to have the awareness of this guideline, and the expertise to apply it.
However, I think it is more than fair to demand this level of understanding from the group of people in charge of maintaining and reviewing the code. In other words: Those with CR+2 permissions. If someone with CR+2 permission on a repository does not know when a change requires more input or input from others, their access was likely granted too soon. As much as I dislike the thought of raising a barrier, we cannot afford distrust on Code Review. I'd rather have other reviewers (incl. myself) spend more time rapid-merging changes +1'ed by various specific people, then to have to go through post-merge because we can't trust their abilities. And besides, this is already an established policy: Gerrit/+2.
In reviewing the charter document just now, I see that the "Scope" section already describes the relationship to "Developers with +2 rights".
T-Comm members cannot monitor every possible repository commit or Phabricator task, so they must rely on the cooperation of others. Developers with +2 rights in any repo deployed at Wikimedia or included in MediaWiki tarballs, as well as managers or others who work with those technical projects, should watch for relevant issues.
@Anomie: Does that satisfy your concern? It essentially answers the question "Does every change require sign-off from ArchCom?" by saying: No, but every change does require sign-off from a reviewer.
That still doesn't tell me, as a reviewer, whether "common sense" is that any particular change should be reviewed by the committee or not. I'll wind up making my own judgments as to when to ignore the overbroad requirements stated here, as will other people, and our judgments will probably differ in some cases.
People with +2 rights are trusted to come to a sane conclusion when making up your own mind.
What's the alternative? An exhaustive list of precise criteria that can be evaluated objectively without judgement based on personal experience? I don't believe that's even possible.
We can try to be a bit more precise, sure; but subjective judgement from experience will always be a factor.
Being a bit more precise is my point. Right now you're saying "almost everything" and hoping people will narrow it down in practice.
Would it help to include an example or two that would not warrant involving the TC? If we could find a couple edge cases, and explain how one might decide which side they fall on, that could be helpful. On the other hand, that might not belong in the charter...but on the third hand, I'm not sure where else it would go.
@Anomie how do you suggest to limit the scope?
Scope creep is a thing, but it's usually countered by the fact that resources are limited. The committee isn't going to want a say in every detail, simply because it couldn't possibly handle the work load.
We removed the example (artifacts or public APIs) from the "Hard to undo" bullet. Hopefully this puts the emphasis back on "hard to undo", where it belongs, and avoids implying that every public API change would have to go before the committee.
Eventually, we envision creating documentation outside the charter, which would give more precise guidance, with examples, as to what changes would rise the level of deserving committee review.
@Anomie: Does that address your concerns? It remains a judgment call, but at least now we're (hopefully) not giving misleading guidance.