RFC: Joining the .NET Foundation

[christophwille]

This got started here #1522 (comment), this issue is intended to continue that discussion.

[jongalloway]

I think ILSpy would be a great fit for the .NET Foundation. Our model is to support self-governing projects, and membership would allow us to provide code signing certificates, use of code signing server, promotion, etc.

I'm happy to answer any questions.

The checklist for new projects is here: https://github.com/dotnet/foundation/blob/master/guidance/new-projects.md

[christophwille]

Do I read that correctly that all past contributors would have to retroactively sign the CLA?

[jongalloway]

For projects like ILSpy that have had multiple contributors over years, we have the top contributors sign the initial CLA. Looking at the contributor graph in GitHub, that looks like the top 4 people. If there's a long commit history outside of GitHub, we'd rely on you to tell us who the main contributors to the project have been.

[siegfriedpammer]

This is the list of the top 10 contributors (git blame line count):

Output of git grep --cached -I -l -z -e '' | xargs -0 -n1 git blame --line-porcelain | grep "^author " | sort | uniq -c | sort -nr truncated

131059 author Siegfried Pammer
73318 author Daniel Grunwald
2784 author Chicken-Bones
2660 author MysticBoy
2080 author Ed Harvey
1757 author Andreas Weizel
1370 author Christoph Wille
878 author Andrey Shchekin
768 author lrieger
681 author Eusebiu Marcu

Note that this does not include contributors to SharpTreeView (from SharpDevelop) and NRefactory.

[christophwille]

A thing re: contributions we need to sort out is which repositories do we consider "core" to ILSpy:

• https://github.com/icsharpcode/ILSpy/ (for sure)
• https://github.com/icsharpcode/ILSpy-tests (yes)
• https://github.com/icsharpcode/AvaloniaILSpy (because it might be the future UI of ILSpy in this repo?)
• https://github.com/icsharpcode/ilspy-vscode (separate because it uses the NuGet?)

The SharpTreeView & NRefactory is not such a big issue because SharpDevelop (where those originate from) had a JCA regimen in place.

[christophwille]

New maturity ladder: https://dotnetfoundation.org/blog/2019/09/23/growing-the-net-ecosystem-through-shared-models-of-quality-confidence-and-support

[jongalloway]

Very interested in your thoughts on it! The repo is here: https://github.com/dotnet-foundation/project-maturity-model

[christophwille]

The plan was/is to discuss this issue in person at our dev meeting (which starts this Friday). I see no insurmountable problems, just a bit of stuff no one really wants to deal with :-) In general, we should strive for level 3, mostly because Roslyn depends on us (for me personally the continuation policy would be the no1 selling point as we are a "classic" spare-time OSS project).

[christophwille]

We just went over the maturity ladder together here in Stuttgart, here are the annotations:

Level 1 -- Incubator

• Health
  • [[CW: y, MIT]] Uses MIT or other compatible license, and third party contributions are documented in a notice file.
  • [[CW: n, no CA mgmt atm]] Uses the .NET Foundation CLA bot (or acceptable alternative) to manage contributor copyright.
  • [[CW: n, no CoC atm]] Uses .NET Foundation code of conduct (or acceptable alternative).
  • [[CW: y]] Maintainer(s) respond to and fix issues and encourage community contribution.
  • [[CW: y]] CI/nightly builds are active, usable and their status is visible (by a badge). The build server must be patched and otherwise be considered secure.
  • [[CW: depends on availability of maintainers]] Publishes new stable versions regularly (possibly just patch updates), at least once/year, but ideally at least once/quarter.
  • [[CW: n, we'd be mostly accepting our own PRs]] Most code changes are performed via PRs, and open to community feedback and transparent viewing. The specific review and merge process used is a project choice.
  • [[CW: n, no policy]] Versioning and breaking change policy is documented.
  • [[CW: n, this is pretty fluid]] Roadmap is documented, via formal document and/or an issue query.
  • [[CW: n]] Build scripts are documented and can be readily used by consumers.

Level 2 -- Basic security practices

• Practices
  • [[CW: y, maintainers plus release mgmt accts]] 2FA in place for all accounts (GH, DevOps, NuGet, …).
  • [[CW: y, 6 uses sourcelink, pdb since prev versions]] Builds are reproducible, use sourcelink and publish symbols (portable PDBs) (in-package or as a symbol package).

Level 3 -- High quality project

• Health
  • [[CW: y, Roslyn/LinqPad/SharpLab]] The ecosystem has adopted this project at a significant scale, demonstrated by one or more key metrics, such as package downloads, number of dependent projects on GitHub, or community activity on or related to the project repo(s).
  • [[CW: given specific user base, only partly...]] Project documentation is available for users.
  • [[CW: n]] Documents security vulnerability publishing policy.
  • [[CW: sometimes]] >1 project maintainer.
  • [[CW: n]] Member project of the .NET Foundation.
• Practices
  • [[CW: n, but planned]] Complies with .NET Foundation continuation policies.
  • [[CW: not verified]] Stable packages depend on libraries that are at level Crash wen update checking disabled #2 or higher.
  • [[CW: only zip with non-EV atm]] Signs packages (Note: this refers to digitally signing NuGet packages, not strong naming).
  • [[CW: n]] Uses static analysis tools to validate pedigree and safety.
  • [[CW: n/a]] Applies .NET API design guidelines.
  • [[CW: n/a]] Seeks and applies guidance from .NET Foundation design and architecture group.
  • [[CW: n, we try to keep lockstep with Roslyn min deps]] Updates package references regularly to accommodate servicing updates in dependencies.

[jongalloway]

This is great. Do you have any feedback on our proposal - any requirements you think should be changed, etc.?

[christophwille]

We are a classic "spare time" project, that is the reason that we sort of skirted the questions on roadmap, release schedule, formal PR strategy, and policies. We actually do plan (but life does get in the way), we take contributions that no one had a plan for, we don't always do PRs because who'd review them except us, and vuln publishing policy... same. We simply need to coordinate around who is currently available. Eg after this weekend's dev meeting there will be a planned long-ish pause.

So my feedback: for a lot of smaller OSS projects that have no company backing (even if it is only "on company time") that's a lot of t's to cross. One request though would be to consider moving signing one level lower, mostly because I think the Foundation should push that.