Jakub Kicinski wrote:
[..]
> Would it help if we speak of "open forums" instead of mailing list?
> I think LPC including "hallway track" fall squarely under "conducted
> in a manner typical for the larger subsystem." Here's slightly edited
> version:
>
> Open development
> ----------------
>
> Discussions about user reported issues, and development of new code
> should be conducted in a manner typical for the larger subsystem.
> It is common for development within a single company to be conducted
> behind closed doors. However, development and discussions initiated
> by community members must not be redirected from public to closed forums
> or to private email conversations. Reasonable exceptions to this guidance
> include discussions about security related issues.
>
> > The only issues I see with such talks is that the work when
> > co-authored should be properly marked as such and that
> > reviewews/acks taken behind doors don't have the same meaning
> > as an upstream review, as they may be due to some internal
> > formalities.
> >
> > IMO, the best would instead to give a positive message. E. g.
> > something like:
> >
> > Maintainers must encourage discussions and reviews to happen
> > at public mailing lists, avoiding whenever possible to have
> > internal discussions.
>
> That's not the message, tho. If someone emails a company privately
> that's fine. If company has internal processes for its development -
> also fine (as explicitly called out). I'm trying to set the baseline,
> not describe the ideal world.
>
> I am specifically calling out that if someone submits a patch, or
> reports a regression the correct response is to review it on the list.
> Like a normal person.
> Not reply privately that "it's on the company roadmap, just wait" :|
> Or reply with a patch company has "forgotten to upstream"..
>
> Maybe it's a cultural thing, but to me this is where the relentless
> positivity is counter-productive. I don't want to encourage people
> to be angles. I want them not to do the shitty thing.
>
To be honest I am lost trying to understand who the audience is and what
the actionable takeaway is from the guidance. It sounds like you are
trying to educate drive-by submitters to push back against requests to
take issues off the list. I think that's a reasonable education
campaign, but doesn't that kind of "submitter bill-of-rights" note
belong in Documentation/admin-guide/reporting-{issues,regressions}.rst
as explicit "how to work your issue upstream" guidance?
