Private, since it doesn't really have anything to do with evaluating actual content. FYI, this thread probably should have stayed on core-mentorship for a bit and then jumped directly to the tracker.
Rustom Mody writes:
because (1) you have some support for the idea that at least some of these are unintentional, and therefore candidates for alignment with the rest of the code,
This you means you,
(2) the nature of the issue is
that it's a mixed bag that is going to need to be addressed line by line, and the tracker is much better at doing that (you can piece each file out to a separate issue, and have a "master issue" that blocks on each individual issue),
I guess you meant generic-you here?
and this you is indeed generic-you, although it applies to your case.
BTW, my terminology "blocks" is inaccurate (though in common use on Python channels). The proper term is "the master issue *depends* on each individual issue, and the individual issues are *dependencies* of the master issue."
and (3) these are "easy bugs", so that new contributors (eg, your students) could do the actual patches while discussion of the need is ongoing.
I thought of that but if this meant a rather obese patch with really minor real-contents I assumed this would be premature [for me :-) ]
The point of splitting up the task according to different files is so that each one would get a patch, which could be done by several students (or 3rd parties) individually without coordinating explicitly. Of course you might personally want to take responsibility to screen your students' work, but that's not necessary with this scheme unless your students are very inexperienced and immature, like junior high school. (I don't know what level you're talking about, I'd guess college so this warning doesn't apply. And of course even junior high school students can be reliable -- I think the record youngest committer got the privilege at age 15. I think that's very cool. :-) And of course this is all up to your judgment.
Then the submitted patch would be reviewed "this is better, apply" (which needs to be done by a developer with commit privilege, so at that point they have to review the patch) or "this is unecessary/inappropriate, mark invalid/wontfix and close." After resolving the particular issue, the "master" issue will show fewer blockers.
I don't think this particular technique is discussed in the developer's Guide, but that's the best source for a concise complete description of the submit-review-commit process in Python. I think you mentioned you already read the Developers' Guide but it's easier to repost the URL than search for that post.
https://docs.python.org/devguide/
Regards, Steve