This group is locked. No changes can be made to the group while it is locked.
Re: "Pseudo-DIA" between the Linux Kernel Development Community and its Users - 4/5 Developers are users too
Well, if developers and users are considered roles, then it should work somehow.
Then individuals, e.g., kernel developers, get those roles assigned depending on what they do. When they start up the machine running Linux, they are users (and hence test the bootup sequence, memory management, scheduler, process management of the kernel). When they write and send a patch, they are in the role developers.
For most organizations, they have multiple individuals which of course take both roles eventually.
It should be clear that at least some of the developers contributing code to
What you have proposed is a model and from a process perspective, "users"Agree. I think I need to think more about this as roles, and organizations make decisions on their involvement, e.g., taking the roles for different parts. E.g., the Linux community predates Google as organization. So, for some parts of the kernel, Google was initially only a user and only by time, they also took part in the community and acquired the role of a developer for many parts, while staying of course also an active user. Still both roles and both organizations are still well-defined; there is no definitional problem here.
The definitions in the glossary need to be updated:
Something like: The Linux kernel community is the set of individuals that have had the role "developer" at some point in time.
Similar for User [or downstream integrator (of course, when you boot up Linux, you rarely think about yourself as downstream integrator...)]
I need to think about the exact consequences in the further line of thought; I still think that you can assign activities (e.g., run checkpatch.pl, test a feature in a specific system, ensure proper funding of the feature you want) to roles, and hence individuals and organizations are executing those activities according to the DIA and role assignment, and the amount of a full-fledged development process they would like to see. E.g., a user is free to use a kernel without ensuring that the driver is fully developed, tested etc. If an organization wants to claim following a proper kernel development process, the organization, using the kernel, got some activity assigned by the DIA and needs to execute that activity to take the written DIA and argue full coverage of process activities.
So maybe that just needs to be described better in the document.
The basic observation remains. The full development process needs to be covered by individuals and organizations, acting in two roles, as members in the community and when they want to use it. Different activities and "rules" (criteria for the work being done) apply when they act in those roles. The overall development process quality happens as the sum of the quality of the activities done by everyone acting in two roles, as developer and user (aka downstream integrator).
But really enjoy your vacation now... We got enough parts of work to continue to weave together in this discussion when you are back.