maintainers: Clarify area status definitions #97222
Conversation
Clarify the area status definitions for maintained and odd fixes. Primary change is to acknowledge that a "maintained" area may not have a Maintainer but can have active collaborators that support it. The "odd fixes" status has general support from the community and the level of effort is not great enough to consider requiring official Maintainer/Collaborators. Signed-off-by: David Leach <[email protected]>
|
| # The area has a Maintainer (approved by the TSC) who | ||
| # looks after the area. | ||
| # The area has a Maintainer (approved by the TSC) and/or collaborators | ||
| # who looks after the area. |
There was a problem hiding this comment.
Grammar nit:
| # who looks after the area. | |
| # who look after the area. |
| # | ||
| # * odd fixes: | ||
| # The area gets odd fixes and may have collaborators. | ||
| # The area gets odd fixes from the community. |
There was a problem hiding this comment.
Minor: I would just leave this line as it was ("may have" is true enough. An area may have a collaborator who even if he tries to do a bit, knows is not capable of providing reasonable support and therefore prefers to label it as "odd fixes".)
There was a problem hiding this comment.
i do not think we are ready for such changes while the maintainer discussion is still ongoing. This basically starts diluting the roles as we have them right now and makes the definition of "maintained" vague and the status field useless.
On the technical side, this will fail in the scripting right now, so just changing the documentation is not enough, but this is a side topic.
If we have to give areas with collabs and no maintainers a different status, I would pick something else, we already discussed this a few months ago, but this did not happen because it does expose other issues we are currently discussing.
I still think the TSC maintainer and using the maintainer file for managing that is the source of all issues and that we need to decouple those and use the maintainer file for pure management of who contributed/maintains/collaborates on something and not for how involved or commited someone is in the project.
From what I read, the motiviation for this change is to be able to add new area without maintainers, to be able to manage the process of getting maintainer role as defined in the process right now. This will be lead to more chrun, confusion and inconsistency, and most of all, will lead to a large number of "unmaintained" areas. We should be able to idenitfu maintainers of new areas immediately and while the area is being contributed and not wait from some entity to vet that the original contributor of some code is the right person to maintain it!!
What we should be doing (and started doing that already) is reviewing entries in the file and remove inactive maintainers or move them to collaboratorts not block this because they need to be vetted and approved.
|
@nashif This came out of the process meeting yesterday as an action. If you have time, go back and listen to the discussion thread. I also marked this as draft so we can discuss more. The primary motivation though was to highlight that an area may have assigned collaborators but no maintainer so does that mean an area is "not maintained"? |
5 participants
Clarify the area status definitions for maintained and odd fixes.
Primary change is to acknowledge that a "maintained" area may not have a Maintainer but can have active collaborators that support it.
The "odd fixes" status has general support from the community and the level of effort is not great enough to consider requiring official Maintainer/Collaborators.