On Sat, 13 Jul 2024 18:07:25 +0200 Mauro Carvalho Chehab wrote: > That's basically what I said: such things happen top/down and not at > developer/maintainer level. Sure having it documented somewhere, on > some document that management would actually read can be useful on > discussions, specially when companies hire a third party company to > help with their upstream process. > > The point is: a developer-focused document - or even a submission > document process won't affect how companies do their inner source It's not a developer-focused document, Mauro. I said that the document should *ALSO*, not exclusively inform contributors that delay tactics and dismissing external contributors is not okay in Linux. > development: companies that have internally heavy development teams > will basically keep running their own internal development cycle, > being concerned about upstream only when their product managers > authorize them to publicly disclosure patches. > > If the goal is to create a management awareness about how to better > cope with upstream, then my suggestion is to write a new document > from scratch [1] focusing specifically on that, containing a list of > best practices with focus on orienting management inside companies > about how to deal with developers and maintainers working on > upstream. > > [1] there is a document there already that seems to be focused at > management style, but it doesn't cover any best practices > with regards to innersource/upstream: > > Documentation/process/management-style.rst Like multiple members of the TAB I did have a stab at rewriting management style at some point. It's not easy. Don't let perfect be the enemy of good.
