Community Involvement

[DanWillman]

There's been...a lot... of activity on this repo in the last week. I don't want this to re-hash out any of the feedback that's happened over the last week, but rather I'm interested in looking at how we can expand how the community can best help with things.

I've noticed a few places where folks have called for kzu to step down from leading the maintenance of Moq (the validity of this is out of scope for this discussion) and begin requiring branch policies to prevent things like an unreviewed merge to master. Given the scope of this package, proper policies are probably vital to preventing supply chain attacks (perceived or otherwise). Stakx rightly pointed out that as-is this would be quite difficult to implement given the lack of active maintainers on this project, so I would like to discuss how the community can help put in the work to support the changes that it is asking for.

Some thoughts on the situation, where things maybe should be, and how best to get there:

Call out contributing in main readme

I think github docs is a good example of making it easy for folks to know how to help, so I'll likely reference them more throughout this. But one thing I think they do is calling out Contributing directly in the main page readme. This is nice for new github users that don't know, or existing folks who forget, the convention of using contributing.md to provide that information. Easy win, and super low effort.

Tagging issues

Again, docs issues I think are a good example of lowering the bar to entry. Specific labels makes it easy to figure out things where help wanted or that are a good first issue, and broadens it to let folks contribute how best they can. And it helps alleviate the analysis paralysis for new contributors trying to best figure out where/how to help.

Sign up Moq organization for sponsorship directly

This is one of those things that validity is out of scope for this conversation, but I have seen some folks hesitant to sponsor devlooped/kzu directly because of recent events. Folks would probably be more receptive to sponsoring the Moq organization itself. I assume there's a billing reason for it, but sponsoring a completely different organization seems odd.

Determine, and publish, avenues to bring in additional maintainers

Admittedly, I'm not sure what the policies for maintainers looks like today. By some orgs/repos definitions I would be considered a maintainer due to a merged PR, but it seems that the ability to merge PRs is limited to a few folks. It might be nice to determine guidelines and requirements for adding new maintainers, and then publishing that in the project so interested folks can help out. This is especially useful because it eases the burden of...

Proper branch protection for main

I think Moq is about 75% there, the fact that PRs/builds are required and only maintainers can merge is good, but ideally there should always be another person reviewing these changes. With more active maintainers than just Stakz and Kzu, the burden wouldn't fall to them to be the only ones protecting the integrity and reputation of the project. It might even be worth considering reviewers being a contributor, where a broader audience is able to review, even if they haven't contributed. I can see issues with this approach, so it's far from recommended, but ultimately I would like to see less burden on Stakz/Kzu in the future and allow the community to take a more active role.

This is decidedly not inclusive, I just wanted to start the conversation, so any/all feedback is welcome!

[DanWillman]

I can't tag it, but we should tag this discussion ❤️

[wrexbe]

@DanWillman If the goal here is to prevent him from doing a supply chain attack, keep in mind he has over 300 nuget packages. You would probably end up compromised one way or another if he was hostile, or hijacked.

[tonyqus]

Proper branch protection for main

I somewhat agree on this. But this project is still mainly owned by kzu. It's a kind of private owned project although there are a few non-primary contributors (less than 1000 line code contribution).

If it's a .NET foundation project, definitely we can do that. However, I don't think kzu is willing to donate this project to .NET foundation so far. And .NET foundation may not be willing to take this hot potato as it's hard to calm down the community.

[aschan]

@wrexbe

@DanWillman If the goal here is to prevent him from doing a supply chain attack, keep in mind he has over 300 nuget packages. You would probably end up compromised one way or another if he was hostile, or hijacked.

While this is true it is only semi relevant; the above suggestion is in regards to Moq and not the other packages.

But yes, if any of those other packages are referenced by Moq it will be a problem. So, a part of the proposed policy above should detail the requirements and expectations of other packets referenced as well as documentation, motivation and risk assesment of said packages.

[stakx]

Call out contributing in main readme
Determine, and publish, avenues to bring in additional maintainers

One thing we can perhaps take away here is that while we already have a CONTRIBUTING.md document, it focuses only on some technical bits (like how to properly submit issues and PRs). What it doesn't go into at all is how one would go about becoming a regular project collaborator / maintainer, and what the expectations for that role would be. Perhaps we could add a section regarding that.

If we wanted to go even futher, it might be necessary to add a CODE_OF_CONDUCT.md document or similar that describes (among other things) how the project is being governed. This would probably take more time than the above to figure out, due to the ongoing discussions and uncertainties surrounding this very topic.