Jakub Kicinski wrote: [..] > > So if this goes in as is, so be it, but it feels like a missed > > opportunity to extoll the virtues of open development. The benefits are > > in the same vector as the "release early, release often" guidance where > > the urge to polish a solution in private is a common trait of newcomers. > > Lets document some tribal knowledge of how one moves past that first > > instinct. > > Hm, the disconnect may be that you think this happens with maintainers > without upstream experience. So we can train them up to be better. > In most cases it happens to folks with experience who are good > maintainers. They just get 2 orders of magnitudes more patches from > inside the company that outside. Then a contribution comes from outside, > the maintainer is overworked, and tries to shoehorn the patch into the > existing, internal-only process. Oh, ok, I was failing to grok that from "Open development" note in isolation. If the guidance is for maintainers, I would say just put your changelog directly into the docuementation, that reads as specific and actionable to me. For submitters an update to reporting-* might be also be useful to remind them to push back on requests to go off-list, but not necessary.
