You touch on many points. Each one needs clarification. I will try and group them and answer what I can, when I can. But first, I need to point out a major flaw in your logic.
You imply that if someone is not voted in (I presume you mean via MNO Treasury Vote for a Proposal) then that person is not part of the team. How does that work for the 90%+ of effort building PIVX over the years, that was done by volunteers? Many are STILL volunteering. Are you saying they should never have volunteered? Or that they shouldn't have access to anything to actually do the volunteer work? This is exactly why the PIVX DAO is more than just the MNOs voting on proposals. It is the Community too. In fact, that is by far a much larger part of it. This is why the MNOs can only control the flow of funds.
You can't stop a PIVian from volunteering. If you could, pretty much anyone could kill PIVX. Who gets to do what in PIVX, is based on the Meritocracy organization model. The more ability and talent you have, the more power and authority you get. Your wealth does not matter. For example, briefly, I was the PIVX Business Development Manager, because there was a need, and no one else was available. Recognizing Jeffrey is WAY WAY better at it than me, and given I was really just a temporary 'place-holder', I immediately did a hand-over. Why? Because that was the best for PIVX. No MNO vote required. Jeffrey then quickly proved himself first by volunteering for a month, and then submitted a proposal. Having said that, if there were multiple people doing Business Development, AND submitting proposals, I'm pretty sure Jeffrey would have left the others in the dust and the MNOs would have stopped funding the others.
Now, I will address the points I think apply to Development. Note, I have not developed code for almost 10 years, and I was 'good', but not 'great'. I used GitHub but in a minimal fashion.
Development:
Devs are not voted in or out.
All start by volunteering, picking an issue to resolve, completing it, and submitting a PR. That is then reviewed by a other Devs, following a long standing and proven process.
If they are having fun contributing, but don't want the deadlines and pressure that comes with submitting a proposal, they can just keep volunteering. However, once they prove themselves, they can submit a proposal to be paid.
If it passes and they get paid, they are expected to deliver what they said they would. If they fail to do so, they can explain, and perhaps keep working without additional funding until it is done or explain why it became far more work than anyone could have known, and request more funding in the next proposal.
If it fails to pass and they want to keep working, perhaps at a slower pace, they are welcome to do so.
If it fails and they need to move to a paying gig, that's fine too.
The way GitHub works, is code is written and the Dev asks for it to be merged into the code base. There have been times when code was ready to merge, but the long standing process that protects all the Devs, requires a certain number of reviewers before code is merged. The purpose of this is so that if the Dev tries to insert malicious code, it will be caught, and that Dev will be ejected from the team. Or, a legitimate bug was missed by everyone, and it would create a vulnerability that could be exploited. If a sole Developer, or even only 2, reviewed the code, and honestly let a bug slip thru, then that mistake could not only severely damage PIVX, the Internet trolls would assume they did it on purpose, and eat them alive. This is why v6.0 progress is so slow - because there are not enough Devs available to review the code submitted. The scenario you reference was likely a case of a single Developer, or too few reviewers, or an organized coup. Having multiple reviewers (I am not certain the number currently required) protects everyone from both malicious efforts, and honest mistakes.
Also, the way GitHub works, is that there are copies of the code base on every Developer's computer, plus on GitHub etc. Control over the GitHub account itself stays with only the most trusted individual(s). Not every Developer can delete the GitHub repositories.
We don't need to create guidelines how to handle these scenarios. They are already in place, (written or verbal - it doesn't matter) and have worked for PIVX since 2016, as well as pretty much any of the millions of Open Source projects out there since the GPL was created.
In fact, detailing the PIVX Specific details in guidelines could be considered poor Op-Sec.
I am not sure why you want to control GitHub access. You know nothing about it. I personally know very little, and I am perfectly fine with the way things are. In fact, even if it were possible to have MNOs control GitHub access, I bet that would be FAR riskier to PIVX than just letting the professionals take care of that. People don't know everything that goes on in the background, nor do they need to. Life is much easier when you trust the right people and let them do their thing.
I should add this .... you are implying that who the Developers are, who has what level of access to GitHub, and who controls GitHub, etc. etc, all be CENTRALIZED with the MNOs, who are pretty much IGNORANT of the knowledge needed to make those decisions. That's a recipe for dissaster.
That's all I have to say for now. Going to go watch the sunset over the Pacific now. Cheers!
