.NET Foundation Project Archival Process - Input wanted

[nicoleabuhakmeh]

In the Project Committee meeting on July 13th, @sbwalker alerted everyone to the news that the .NET Foundation Board approved starting the Project Archival Process at the June Board Meeting.

".NET Foundation Project Membership is predicated upon a project maintaining its eligibility status, abiding by the code of conduct, and demonstrating continuous contributions via its public activity metrics (ie. code commits to their repository within the past 18 months). If a project fails to meet any of these requirements, the project maintainer will be notified so that they can return the project to good standing. If the project is still unable to meet its obligations, it will be archived. Archival means that the project will no longer be represented as an official Member Project and will no longer be eligible to receive Member Project benefits."

The committee members will start the work on defining what this means for projects that fall into this status and how it will work.
Feel free to leave any feedback or comments here if you are unable to attend the next meeting.

Idea on guidelines:
Projects that don't have any commits for 18 months
Archival process steps

The next meeting is scheduled for August 10th.

[ChrisHammond]

Question for the community: Does anyone feel that there is value in projects being kept in the support of the Foundation if they are no longer actively being maintained with commits?

[robmen]

I think it is good that the .NET Foundation "hold on to the keys to the kingdom" for archived projects in case a new maintainer comes along to pick up the project.

Archived projects are essentially labeled up for grabs. 🤣

[glennawatson]

The name archiving is likely a bad name. Retirement or removal conveys to users what it is about.

Also we should probably have some discussion around how long we wait before actioning any retirement processes. For example I would want to allow ample time in case a maintainer is sick in hospital or on a extended vacation to allow for them to have time to get back to the foundation

Also projects maintainers do change, and we might want to reach out to more than just the original registered maintainer, and do a active search on the commits of the project.

[glennawatson]

I think it is good that the .NET Foundation "hold on to the keys to the kingdom" for archived projects in case a new maintainer comes along to pick up the project.

Archived projects are essentially labeled up for grabs. 🤣

I guess that'd dependent on the model that the foundation took on the project under. Eg if contribution the original owner still owns the property. Nothing stopping anyone forking the project then getting blessed to joined the foundation with the new contribution maybe.

[robmen]

IANAL, but I don't understand why the contribution model to .NET Foundation matters. The original copyright holders will always own the parts that they wrote, but that doesn't (AFAIK) prevent others from building on that content (because we're using OSI licenses).

My (uneducated) thinking was that if the maintainers bailed, the .NET Foundation would archive the project in GitHub. There could be a cost of maintaining a domain name for the project if the .NET Foundation owns that, but what other costs are there?

Should a new maintainer show up, the .NET Foundation could unarchive the project, add the maintainer to the project, and the project continues building on top of the original content.

Or... as you say, don't use the word "Archive". Call it something like "Honorable Discharge," and the project is out. If someone forks it and continues, that fork could reapply for the .NET Foundation, as you suggest.

[glennawatson]

Putting my maintainer hat back on rather than board member.

I hated it when the foundation had admin access. Although well meaning I found a few times where I would just have random changes happen from the admin account so ended up disabling unless asked.

I guess with DNF signing though in theory another repo could take over the nuget pushing?

[robmen]

That's a good point. I guess I've been assuming the maintainers leave in an orderly manner, but I suppose it is far more likely they simply ghost everyone.

Maybe "discharging" projects is the only option. You could have both "Honorable Discharge" for those projects that shut down orderly (i.e., communicating with the Foundation) and "Dishonorable Discharge" for those that bail on everyone. I'm only half joking; the more I think about it, the more I like it. 😄

I hated it when the foundation had admin access.

💯

[Perksey]

For the contribution model, it may seem inappropriate the .NET Foundation (not holding the copyright) being the ones to mark the project as archived. However, this may be the only option after time.

My thoughts:

• The .NET Foundation does need to maintain a requirement for active communication channels. There needs to be processes around keeping maintainer contacts up-to-date.
• 18 months sounds good. If they have no longer met the requirements, the .NET Foundation should contact the maintainers and illustrate steps to comply.
• If active communication channels are established with the maintainer and they are still non-compliant, you should give the maintainer a choice:
  • Removal of Project - this is the same removal process that ImageSharp underwent.
  • Archival of Project - project is archived and the .NET Foundation shall retain it's IPR license should another party approach the .NET Foundation to revive the project.
• If the assignment model is used, there is no obvious copyright holder for the IPR to be transferred to therefore the Archival of Project should be used.
• If no active communication channels are established with the maintainer and they are still non-compliant, use the Archival of Project choice.
• The .NET Foundation needs a process for another party to take on maintenance of an archived .NET Foundation project.

Nag: Despite vocal complaints and also apparently Virtual Inc assigning someone specifically to establishing formal processes (at least this is what Tom Pappas told me), there is no central location where formal processes can be accessed. None of this matters unless that's established. Yes I know nobody in the .NET Foundation has time but this is a valuable investment because without formal processes the .NET Foundation is completely unable to do anything right consistently. And "contact Chris" is not a process!

[sbwalker]

The consequence of a project failing to remain "active" or in compliance with the criteria in the Project Charter was summarized as:

"If the project is still unable to meet its obligations, it will be archived. Archival means that the project will no longer be represented as an official Member Project and will no longer be eligible to receive Member Project benefits."

To provide clarification:

• "will no longer be represented as an official Member Project"

Basically this means that a reference to the project name/url would be removed from various public locations where official .NET Foundation projects are maintained ie. the project would no longer be officially "endorsed" by the .NET Foundation. It does NOT mean that project would cease to exist - the repos would still be available on GitHub, the Nuget packages would still be available for download, etc...

• "will no longer be eligible to receive Member Project benefits"

This means that the project would no longer be eligible to receive .NET Foundation benefits listed on this page: https://dotnetfoundation.org/projects/benefits . The majority of Member projects do not utilize all of these benefits, but for projects which have been identified for archiving and who have no plan to continue maintaining the project, the .NET Foundation would need to work out a seamless transition plan in the event they were utilizing any of the benefits.

[sbwalker]

It may also help to provide some further context in the form of actual .NET Foundation Member Projects which currently fall into the "inactive" category (ie. no commits to their repository for the past 18 months):

Community Projects:

ChronoZoom https://github.com/alterm4nn/ChronoZoom
ConferenceXP https://github.com/conferencexp/conferencexp
AJAX Control Toolkit https://github.com/DevExpress/AjaxControlToolkit
Facebook.NET https://github.com/facebook-csharp-sdk/facebook-csharp-sdk
IdentityManager2 https://github.com/IdentityManager/IdentityManager2
OData Validation https://github.com/OData/ValidationTool
Open Live Writer https://github.com/OpenLiveWriter/OpenLiveWriter
Force.com Toolkit https://github.com/wadewegner/Force.com-Toolkit-for-NET

Microsoft Projects:

WebForms MVP https://github.com/webformsmvp/webformsmvp
Xamarin Auth https://github.com/xamarin/Xamarin.Auth
Xamarin Mobile https://github.com/xamarin/Xamarin.Mobile

[glennawatson]

Nag: Despite vocal complaints and also apparently Virtual Inc assigning someone specifically to establishing formal processes (at least this is what Tom Pappas told me), there is no central location where formal processes can be accessed. None of this matters unless that's established. Yes I know nobody in the .NET Foundation has time but this is a valuable investment because without formal processes the .NET Foundation is completely unable to do anything right consistently. And "contact Chris" is not a process!

I think a goal at the moment is probably to reduce the large number of ways to contact us. Probably Discord (as much as I'm not a fan it is where the rest of the .NET Community is) and one email. Likely reduce the number of repos we have as well to reduce our burden, and use github issue forms to determine automated categories etc.

[IntegerMan]

I think we need to be very cautious with a change like this. The 18 month guideline is a good one, but you may also want to add an AND guideline, possibly involving monthly downloads being below a certain marker. In other words, the project should not be getting active commits and should not be getting regular downloads of a substantial nature. The case we want to protect against is when you have a library that is more or less in finished state, but still getting regular usage from the community. Sure the library could get regular upgrades from .NET versions, but even with that with LTS coming out every other year, there might not be a compelling reason to commit every year.

I guess the benefits from archival should outweigh the potential for drama in archiving a project in maintenance mode getting regular traffic.

[glennawatson]

@IntegerMan There could be a argument maybe for extending out to the LTS release schedule I guess, like 2 months after being a deadline for a commit/release.

Commits by themselves are meaningless in some ways right.

[tonyqus]

I suggest you create a DNF-owned OSS list and monitor the last commit date as the one I did for China market:
https://github.com/dotnet-cn/OSSRanking

There should be some detailed rule about how to determine the project is inactive or in maintainence mode.