Centralised information for .NET Foundation operation

[Perksey]

So I was going to pile this onto #60, but decided not to as that's a very well-encapsulated discussion and a very promising one at that.

---

Reasoning

In the .NET Foundation as it currently stands the general operation is quite undocumented. There are bylaws, and a document here and there per-committee, but beyond that a lot of the day-to-day operations of the .NET Foundation just seems to be "go with the flow" being anchored by quite high-level, catch-all aims. This has resulted in miscommunications (or no communication at all), unclear objectives, and/or disgruntled members.

General Idea

Forgive me for sounding incredibly boring, but I believe what the .NET Foundation does and its objectives for doing so should be documented in the form of a library of processes. That way, anything the .NET Foundation does is process-driven, and provided the day-to-day execution of such processes are delegated to committees where appropriate, the board's responsibilities and scope will shrink to just maintaining these processes and supporting the committees in executing them.

Don't get me wrong, it'd be an incredibly boring process (ha) to document all of this, but I believe if everything the .NET Foundation routinely does/any rinse-and-repeat formulas are documented, it'd create a lot more clarity on what to expect from the Foundation, and will ultimately answer the big question floating around along the lines of "what does the Foundation actually do". This has benefits for the board members, present and future; as well as the members and maintainers.

In addition these should probably:

• be centralised in a single location, such as a single repository, so everything is placed on a single plane rather than being scattered around.
• have expiration dates, so when the board is swapped out they can keep on top of what the foundation does

(Possibly Very Poor) Prototype Implementation of That Idea

If we had something like

• dotnet-foundation/management
  • overview (containing high-level/less formal info on the foundation for newcomers who don't necessarily need the full scoop)
  • policies (containing what the foundation wants to do)
    • POL001-Director_Election_Policy.md
    • POL002-Membership_Policy.md
    • POL003-Project_Governance_Policy.md
    • etc...
  • processes (low-level, specific information on what the foundation does to implement policies)
    • PRC001-New_Project_Evaluation.md - (e.g. given a project, what the projects committee does to determine if it's eligible or ineligible - activity metrics, licenses, etc)
    • PRC002-Project_Code_Signing.md - (e.g. given a project, what steps are taken to facilitate code signing for that project through the .NET Foundation)
    • PRC003-DevOps_Management.md - (e.g. allocation of GitHub resources, how projects are given access to these resources)
    • PRC004-Access_Management.md - (e.g. how the foundation manages, audits, and distributes access to foundation resources, including those vested in the foundation by a project)
    • PRC005-Project_Domain_Names.md
    • PRC006-Server_Hosting_Allocation.md
    • etc...

i.e.

• The policies contain the overarching goals and requirements for the .NET Foundation, and shouldn't contain any detail on how it would be accomplished.
• The processes implement a solution for those requirements and link back to the policies, and should be as in-detail as possible focusing on a specific aspect of implementing those requirements.

Closing

Perhaps it's a bit too much of a business-oriented idea that isn't really applicable for a volunteer organisation, or perhaps it's a bit of a crude "treating the .NET Foundation like an in-development product" with the whole 'requirements'/'implementation' thing, but either way I do think the routine stuff the foundation does and why it does it should be documented, ideally in a single location so it's all available in one place for anyone who wants to seek that info out.

[rprouse]

Thanks for this @Perksey, it is well thought out and a good start to what we need. I think the biggest issue implementing this is getting enough help to complete the process. I personally think that a lot of the issues we have are because we don't have the manpower to do everything we should be doing. I think we need to get the community involved and engaged for that to improve and I'm hoping these last few weeks will help with that.

[nathan-alden-sr]

Forgive the blunt question, but what is the purpose of a whole page of smiling director faces if not to handle the strategy of the corporation, modify Bylaws, document processes, etc.? If the directorship doesn't have enough time then you need to elect directors that do. The directors of a non-profit have a legal duty to perform their duties as described in Bylaws.

[Perksey]

For the record, I'd be more than happy to help formalise proper policies and processes (not sure what committee this'd fall under, perhaps a new one?)

But my main worry is a lot of this information is centralised with the board, which means we'd have to use the board for consultancy quite frequently in making these documents as is. This could be solved by a massive information dump to whoever will end up writing these formal documents, but that's still on the board to do.

Again, would love to help just not sure how without burdening the board to a similar extent as if the board wrote these documents themselves!

[michael-hawker]

I've been trying to figure out the right folks to talk to about something similar last year before the discussions were setup here. For instance, I still don't know who to contact to add someone to the DevOps organization...

It'd be really great to have this repo not only contain all the process docs, but enable the Wiki as well to mobilize our communities to help one another or get basic guidance on common questions that come up when maintaining a project. Something project owners can use to understand how to handle them directly without needing to reach-out and self-serve or find out how to get support from the foundation for more complex cases. Having any of these documented in a searchable and accessible format would be an amazing help and benefit.

For instance, here are some of the things that I've wondered about, still wondering about, or forget the answers to over time (especially when processes change or the people involved move roles):

• Section on adopting the Code of Conduct and onboarding a project into the Foundation
  • How to change headers and adopt the License
  • Getting the CLA bot setup
  • How to handle disputes with members in the community
    • Someone breaking the code of conduct
    • What if it’s a philosophical/technical dispute, like conflict resolution tips
• Community Management in general
  • .NET Foundation groups - Committees & Meet-ups
  • Communities for folks working across project to engage on (like Discord servers for C#, UWP, and DotNetEvolution) – Is there still a Slack channel somewhere?
  • Guides on managing a community on GitHub (Issues, PRs, Discussions, Planning, etc…)
• .NET Events and Marketing
  • Adding info to the Newsletter
  • .NET Conf and other events - timelines, tips for submissions, etc...
  • How to add/modify/remove the Project info Page
  • Speaker Page
  • Links to Branding guidelines
  • Links to .NET Foundation social media accounts for amplification/messaging
• DevOps stuff
  • Adding folks to the .NET Foundation org to add to a project
  • Signing Certificate setup/usage
  • Pushing to NuGet
• Nuget.org stuff
  • Assigning ownership to the dotnetfoundation account
  • Microsoft.* package identity info, restrictions, etc...
• Legal Stuff
  • How to properly reference code adopted from another project, in and outside the foundation, with the same license or others
    • What factors should matter for what licenses?
      • How does this change if it’s another .NET Foundation project as it’s all the same license, can we simply provide a commit hash link and be done or still do more?
    • How should that code be ingested and attributed in the header of the file it’s used (what if it’s a whole file or just a blurb of code as part of a larger file)
    • Attribution at the project itself (i.e. third-party license file)
  • How folks should properly reference code adopted from a foundation project
    • Either source code used as part of another project
    • Just referencing the library via NuGet as part of another piece of software
    • What to do if you find a violation of a project not referencing code/libraries correctly
  • How to relicense a piece of software
    • What steps are involved (and risks)
    • What licenses are compatible to migrate, etc…
    • (More from the Microsoft side but we know it happens often) How to release code from MS to the Foundation (or vice-versa)
  • How to adopt a new repo from GitHub into a .NET Foundation org
    • Ramifications and Process (e.g. transfer not as straight-forward if someone outside the organization of the target repo, have to move to an individual in the repo first and then to the org)
    • Some of the questions above about onboarding/licensing correlate to this, like how to adjust source code headers or re-license

[michael-hawker]

A dedicated GitHub repo for a wiki could be a good implementation to host this information (and provide tracking/history for documenting individual questions/topics/processes). It could be auto-mirrored, so it could be centralized on the dotnet-foundation/Home repo here as the 'Wiki' tab for instance.

For example, for my project have our Wiki here on our main repo: https://github.com/CommunityToolkit/WindowsCommunityToolkit/wiki

But it's auto-pushed and updated from this dedicated repo: https://github.com/CommunityToolkit/WindowsCommunityToolkit-wiki