Skip to content
This repository has been archived by the owner on Jul 29, 2021. It is now read-only.

Dispute resolution and support policies #13

Open
glennawatson opened this issue Sep 25, 2019 · 7 comments
Open

Dispute resolution and support policies #13

glennawatson opened this issue Sep 25, 2019 · 7 comments

Comments

@glennawatson
Copy link
Contributor

glennawatson commented Sep 25, 2019

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 glennawatson changed the title Dotnet Foundation Issues Dispute resolution and support policies Sep 25, 2019
@glennawatson
Copy link
Contributor Author

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
Copy link

haacked commented Sep 26, 2019

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link

haacked commented Sep 27, 2019

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
Copy link
Contributor Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants