dotnet-foundation / project-maturity-model

Proposal/RFC for new .NET library development model.
MIT License
39 stars 9 forks source link

Dispute resolution and support policies #13

Open glennawatson opened 5 years ago

glennawatson commented 5 years ago

There doesn't seem to be any sort of dispute resolution policies with the set of documents. How you handle if either party (the dotnet foundation or the project maintainers) have issues on either side.

Also what the ramifications from both parties side in the arrangement if they fail to resolve issues.

Main reason why I bring it up in the past there have been communication issues with the dot net foundation and might be worth listing that.

Also it might be great for there to be a set of support policies for projects/maintainers that the DNF would provide beyond the very technical aspects listed, and how to get support for those items.

glennawatson commented 5 years ago

Essentially there should be documented contact methods for handling disputes between the .net foundation and maintainers which includes time lines for either side to respond. There should also be documented procedures if either side fails to respond to the communication. Ideally on the .net foundation something somewhat private where multiple sets of eyes can overview it so that if someone is on vacation others can take over.

Since there are punitive sections of this proposal having these things documented with procedures is critical.

haacked commented 5 years ago

Seems like this is broader than the maturity ladder. There should be a general Foundation level dispute resolution process. Or do you think there should be one specific to the ladder? If so, what's a strawperson proposal for it?

glennawatson commented 5 years ago

Could be arguments for either. But I would want a process around the punitive processes mentioned in the proposal at least and how it's handled.

I would would like description how the communication is done in regards to a ladder drop for example, how the maintainer can communicate back and if they don't agree with the representative from the foundation maybe having a decision done at the board level.

Maybe even describing how the drop in level or forking is done for example.

glennawatson commented 5 years ago

Here's a sample of resolutions I would forsee.

Scenario: Maintainer discriminates against LGBT consumer. Actions: Complainant sends a email to a distribution list hosted by the DNF which gets distributed to the board members. The email covers discrimination for example where consumer was blocked from the channel. A board member will generate a github team under the "Board Members Only" category. This means communication will only be between board members and the maintainer. Board member will suspend access for maintainer to DNF infrastructure Board member will put portions of the complaint onto the GitHub teams and add the maintainer. Board member asks the maintainer to put their side forward. Board formally meets within 60 days and decides on the matter.

This would mitigate risks such as if former maintainer goes to a lawyer, makes a request for discovery. All the material is there. Also for deciding as a board makes all the information easily available to all board members.

Scenario: Project changes to new security scanning software Actions: Technical advisory finds the case that new security scanning software is inadequate compared to old solution. Technical advisory asks board to generate a teams chat for the project case. Board member adds technical advisors, mentor, and maintainers of the project. This teams chat is listed under Project Leads/Technical Advisor permissions indicating current maintainers are allowed access along with technical advisors/mentors. Technical advisory adds details about the pro/cons, and technical references to the advisory. Maintainers disagree with the advisory and put their own notes why they disagree, but neither technical advisors nor maintainers agree. Board meets within 60 days and each board member is able to look at material supplied from all parties. If board decides that the project is not maintaining their ladder requirements a statement of findings is posted to the team post. Having this in the GitHub teams post will allow future maintainers to see advisories and be able to take control.

Bottom line it would be useful to have timelines/communication avenues/the security clearance to the communication mechanism, and ideally some forum/team chat scenario to avoid fishing around emails. Also it'd be useful for future maintainers/legal.

glennawatson commented 5 years ago

Given the clarifications that have been going on I think still having a dispute process is important but the tone for moving between maturity positions doesn't need to sound so strict. The points after hate speech etc should definitely keep the stricter tone though but as Phil pointed out we may refer to more of a global dnf policy.

haacked commented 5 years ago

Yeah, I think we may want to move this issue to https://github.com/dotnet-foundation/home. The result of the policy should be published on the website too.

glennawatson commented 5 years ago

As long as the movement between tiers policy is made into a separate issue. Eg who decides etc