Dragonfly governance follow-up items

[mrbobbytables]

ref: cncf/toc#1358
cc: @gaius-qi @imeoer

Following up on the Dragonfly governance review being performed by @khallai, there are suggestions that should help resolve the majority of the findings. It's largely a lot of clean up and consolidation with a few suggested policy items and the adoption of some tooling that would streamline management in the future. If you have any questions, please don't hesitate to ask 👍

1. Consolidate governance documentation:
   1. Dragonfly has a community repo that seems like it is intended to serve as the central point for project governance and docs, however docs and links there appear to be out of date and broken when compared to the docs in the dragonflyoss/dragonfly repo.
      1. No governance.md file in community repo, link in readme broken
      2. Most recent governance.md exists in dragonflyoss/dragonfly repo
      3. Security process in contributing.md refers to an alibaba address to contact for reporting vulnerabilities vs contributing.md in dragonfly repo.
   2. Post consolidation, update all associated links to point to single source of truth.
2. Consolidate and update security policy / contributing.md security section
   1. Security policies should be consolidated (some say report via GitHub security, others email list)
   2. Reporting security vulnerabilities should not be directed to a public mailing list, suggest using dragonfly-maintainers@googlegroups.com, or another limited group (administrators?), instead of dragonfly-developers@googlegroups.com.
      1. This would serve as the project’s “Security Response Team”.
   3. No way listed to join security-announce mailing list (unless its dragonfly-developers?).
3. Update contributing.md
   1. Could use an update to reflect current state (e.g. references go 1.15).
      1. For the current go version, you can say “check go.mod” for current required version so that you do not have to update every time golang is bumped.
      2. Alternatively to further consolidate docs to one location, you could point to the developer docs on the dragonfly website.
4. Update Code of Conduct to reflect CNCF policy
   1. Code of Conduct currently references the Contributor Covenant, projects are required to adopt the CNCF CoC as part of joining the foundation.
   2. Suggest adopting a policy similar to Dapr.
5. Communication channels
   1. dragonfly-maintainers@googlegroups.com is not documented
   2. Most communication channels are only listed in the README of the dragonflyoss/dragonfly repo.
   3. Googlegroups link list the email of the group, suggest either linking to the group itself e.g.: https://groups.google.com/g/dragonfly-discuss
      1. In the case of dragonfly-discuss, suggest removing it and only using the GitHub discussions. They have much more engagement vs the mailing list which only has 15 posts (mostly spam).
   4. Email list spam
      1. For public googlegroups channels, suggest setting first post moderation on for google group settings. Users that submit a valid message would never need follow-up approval, spammers would be banned.
6. Governance
   1. Current governance docs are essentially a contributor ladder with a couple governance sections. Suggest minor edits and renaming to community-membership.md
   2. Adding a maintainer section should be updated
      1. Section requires a meeting to discuss & vote on promoting new maintainers, but it does not look like any meetings are regularly taking place. Suggest updating policy to move to an async method.
   3. Regarding decision making a few suggestions:
      1. Change “maintainer” to “active maintainer” to prevent an inactive member from dry-by “LGTM”ing to merge something without review.
      2. Define a lazy consensus period before a significant PR can be merged when below 7 active maintainers as a secondary mechanism to prevent unintended merges.
   4. Link to security.md for “Security Response Team” to create a single source of truth (or vice-versa).
   5. Administrator role
      1. Who decides who can be an administrator? What happens if all administrators are not available?
         1. Suggest nominated by administrators, voted by maintainers or administrators + maintainers
      2. Facilitating elections is a listed responsibility, but what is the election policy? In the maintainer section it does list supermajority as a means
7. Maintainer List
   1. Maintainer List is out of sync with CNCF maintainer list, and maintainer mailing list.
      1. Updating CNCF maintainer lists is important as those people are allowed to represent the project to the CNCF (service desk tickets) and get important notifications (e.g. CFP deadlines, security issues reported to CNCF).
      2. Some maintainers have not been active and should be removed following current documented policy.
         1. Suggest updating policy to extend inactive timeframe to be more than 3 months, or optional vote at 3 months, and automatic removal at a year, or something similar.
         2. Example: Dapr community-membership.md
         3. Example: Kubernetes Inactive member policy
   2. Suggest adopting cilium/team-manager (config example), clowarden (config example), or other similar tool for managing org membership, team membership etc.
      1. Creating groups for maintainers and administrators and providing name/affiliation in a comment would satisfy keeping a maintainer list, subproject ownership (e.g. of nydus), and would mean it only had to kept up to date in one place (in project).
      2. Team-manager can load-balance PR assignment across members of a group.
8. Community Meetings
   1. Community repo readme states that community meetings take place every month, but it does not appear that they are actively happening with the last meeting taking place on 2024-06-27.
   2. If meetings are not taking place, suggest updating to move to a method to “propose agenda items” and schedule ad-hoc
      1. Would match governance.md with it stating that meetings only happen sporadically.
9. Design Proposal & architecture (not a governance item)
   1. Suggest updating default feature issue template and consolidating on that or an alternative where they can be discussed/tracked in a more formal way.

---

EDIT: Some of the nested lists weren't rendering right, should be fixed now 👍

[gaius-qi]

@mrbobbytables Thank you for the suggestions. We will track the improvements related to the above suggestions in this issue.

[gaius-qi]

@mrbobbytables Dragonfly team has made the changes as suggested. We would appreciate it if you could review them. Thanks! 😊😊😊

1. Consolidate governance documentation @bergwolf
   Update community docs #25
   Consolidate community docs dragonfly#4087

2. Consolidate and update security policy / contributing.md security section @bergwolf
   Update community docs #25

3. Update contributing.md @chlins
   docs: update the required golang version in the contributing.md #31

4. Update Code of Conduct to reflect CNCF policy @chlins
   Update community docs #25

5. Communication channels @gaius-qi
   chore(README.md): add maintainer google groups for communication channels and remove discussion group dragonfly#4093
   chore(README.md): add maintainer google groups for communication channels and remove discussion group helm-charts#380
   chore(README.md): add maintainer google groups for communication channels and remove discussion group api#495
   chore(README.md): add maintainer google groups for communication channels and remove discussion group client#1157
   chore(README.md): add maintainer google groups for communication channels and remove discussion group console#526
   chore(README.md): add maintainer google groups for communication channels and remove discussion group perf-tests#107
   iii: I have removed the dragonfly-discuss and only using the GitHub discussions.
   iv: I have enabled post moderation for the following Google Groups:
   dragonfly-developers@googlegroups.com
   dragonfly-maintainers@googlegroups.com

6. Governance @chlins
   docs: add the GOVERNANCE.md #29
   docs: add community-membership.md #28

7. Maintainer List @LunaWhispers
   i: Add Dragonfly project maintainers cncf/foundation#1021, docs: add community-membership.md #28
   ii.a: We have completed the management of the organization and the various sub-projects under the Teams section of the Dragonfly repository, as shown below. This Teams creates groups for different sub-projects, which makes it easier to maintain and develop each sub-project, as well as manage the team and sub-project team members.
   

   ii.b: https://github.com/dragonflyoss/dragonfly/blob/main/.github/workflows/auto-assign.yml and https://github.com/dragonflyoss/dragonfly /blob/main/.github/auto_assign.yml can balance the PR allocation of team members.

8. Community Meetings @gaius-qi
   docs(README.md): update community meeting process to ad-hoc scheduling #30

9. Design Proposal & architecture (not a governance item) @bergwolf
   Update community docs #25

[mrbobbytables]

Thanks so much @gaius-qi and everyone else involved in opening PRs :)
Overall looks solid! :D

I noticed a few small things and opened this PR: #32
Big thing from there is for security stuff going from dragonfly-discuss to dragonfly-maintainers (private list vs public)

One note on the teams section -
It's teams tab is only visible to members of the org, and not available to the public to see. :x

If you've configured the auto_assign action, I'd suggest using the team management part (Cilium config example which would allow everything to be visible and would make admin level tasks more transparent via PRs 👍

I think with those out of the way it'd knock out the vast majority of stuff that came up in the governance review 👍

[gaius-qi]

Thanks so much @gaius-qi and everyone else involved in opening PRs :) Overall looks solid! :D

I noticed a few small things and opened this PR: #32 Big thing from there is for security stuff going from dragonfly-discuss to dragonfly-maintainers (private list vs public)

One note on the teams section - It's teams tab is only visible to members of the org, and not available to the public to see. :x

If you've configured the auto_assign action, I'd suggest using the team management part (Cilium config example which would allow everything to be visible and would make admin level tasks more transparent via PRs 👍

I think with those out of the way it'd knock out the vast majority of stuff that came up in the governance review 👍

@mrbobbytables Thanks! @mingcheng and @LunaWhispers will complete a more transparent team management as soon as possible.

[mingcheng]

Hi, guys. I've updated the content of the membership file (still in draft), so please review it and let me know if you have any comments.

https://github.com/dragonflyoss/community/blob/chroe/community_membership/COMMUNITY_MEMBERSHIP.md