AIP1 : Proposal Process

[activescott]

I suggest we closely follow the Ethereum Improvement Proposal (EIP) process as documented in eip-1.

I suggest we write an xip-1 to define the process borrowing very heavily from eip-1 (probably copying large portions but maybe keeping it simpler).

Some misc things I like about the eip-1 process:

1. The three types of EIPs (alhtough we may start only with informational, later on contract, organizational, backend, protocol, are all good ways to organize)

2. EIP Work Flow:

   1. A clear lifecycle: Draft > Accepted/Rejected/Withdrawn/Deferred > Final... (Replaced, Updated)
   2. Issuing drafts as pull requests
   3. Each EIP must have a champion - someone who writes the EIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea.

3. Encourages public discussion (I especially like emphasizing github issues)

4. What belongs in a successful EIP?

5. EIP Header Preamble

6. Generally relatively easy process to document and execute.

7. Can be done entirely in github UI without git.

8. Obviously vetted extensively as an EIP

---

Open Issues / TODO

• Near the mention of "We use GitHub's [required reviews for pull requests]" above, but that is for every review/pull of the PR. PRs can be merged in a Draft status without being accepted. More final status (Accepted, Deferred, Rejected, and Replaced, Final) require more careful reviews. That needs clarified. Or we could make a different directory for Draft proposals and Accepted/Finalized/Active/Replaced proposals to keep the review/approval requirement lower for Draft proposals.
  • It can be difficult to easily preserve and view file history across renames, so I think we just require n of M board approvals for ALL pulls and make sure that they are trained to quite liberally merge draft proposals and very judiciously merge proposals with any other "final" status. This also keeps the URL to an AIP intact regardless of status.
• Set up the [@Agorex-io/proposal-editors] team.
• Set up the [@Agorex-io/board-of-directors] team.
  • Initially proposal-editors and board-of-directors are likely to be the same members. Long term this may scale better to keep them separate.
• README.md
• add PULL_REQUEST_TEMPLATE.md
• Document and link to "Agorex values" above.
• Double check by searching for PEP, EIP and Ethereum in doc content.
• Double check by searching for Meta -> Proposal in doc content.
• Low priority:
  • Setup github pages on the repo. Necessary?

[Ebonsignori]

Nice. I like this format for all future requests and suggested changes/improvements to Syndex (temporary).

However, were eip’s made after Etherium had developed and shipped its base product?

We haven’t established our organizational foundations yet. Are xip’s (X improvement proposals) meant to also serve as proposals for our foundations as well?

I think we need a quicker more iterable method of proposals and democratic consensus on early / foundational decisions.

Perhaps xips that address not a specific change, but a broad problem that needs to be addressed and purposes multiple decisions for voting.

For example, a meta xip that addresses our choice of entity. Are we a co-op, a DAO, a nonprofit?

Would this be a single xip, or would there have to be three seperate xips with seperate champtions for co-op, DAO, and nonprofit respectively?

In the big early-on foundational decisions, I think Discord channels (like we are currently doing for structure) whose discussions naturally spawn options are a good starting point. Perhaps polls based on those options can follow?

[activescott]

were eip’s made after Etherium had developed and shipped its base product?

Certainly, that is an active repo and I have multiple times found myself linked to discussions related to an EIP.

We haven’t established our organizational foundations yet. Are xip’s (X improvement proposals) meant to also serve as proposals for our foundations as well?

Yes, that is my proposal ;)

I think we need a quicker more iterable method of proposals and democratic consensus on early / foundational decisions.

Well I think we can certainly discuss them in other public forums (such as discord as we are now), and those early "decisions" should be codified in a xip/proposal for documentation. This provides transparency to the community on what our policies are, and a starting point for refinement in the future.

For example, a meta xip that addresses our choice of entity. Are we a co-op, a DAO, a nonprofit? Would this be a single xip, or would there have to be three seperate xips with seperate champtions for co-op, DAO, and nonprofit respectively?

In this particular example, I think we will probably discuss the choice among a small group of us, put forth a single proposal as a draft, then document it and get it to accepted status once we feel we have the necessary consensus. If however, we had people "championing" two different approaches, it would also be fine to have two proposals by different champions and if they are in conflict, only one should ever reach accepted status.

Anyway, all just my thoughts on how to help us make transparent, deliberate, documented decisions in an fairly organized manner.

[Simon0x]

Well I think we can certainly discuss them in other public forums (such as discord as we are now), and those early "decisions" should be codified in a xip/proposal for documentation. This provides transparency to the community on what our policies are, and a starting point for refinement in the future.

I think it is very profitable to design the project with a transparent policy from the beginning. This creates trust for the community. In addition, public discussions also provide the opportunity for more community participation that can provide good ideas for solutions/implementation.

By the way, it's my first post here, found the project exciting and therefore wanted to actively contribute to the discussion :)

[JonathonDunford]

I really like the EIP proposal process and it has been proven with time (Bitcoin, Ethereum, Python).

I agree with @activescott 's proposed approach to the foundational proposals. If different people would like to champion different approaches, they can bring forth the EIPs.

I think one important question to answer is how will we be voting on EIPs?
Through a DAO?

I see our XIP-1 as the method for creating new proposals, then XIP-2 would become our foundational proposal.

This also means we need to figure out the "XIP editors". I would assume this would be the team of contributors that decided to come over to this project?

The only real con to this sort of proposal process is that it is generally slower than just voting on decisions, but I believe the pros outweigh the cons.

[Ebonsignori]

Perhaps we could use a mixture of XIPs and another form of decision making for less important everyday decisions? We would need a formal method of distinguishing 'less important everyday decisions' and important decisions that effect the community.

@activescott

In this particular example, I think we will probably discuss the choice among a small group of us, put forth a single proposal as a draft, then document it and get it to accepted status once we feel we have the necessary consensus. If however, we had people "championing" two different approaches, it would also be fine to have two proposals by different champions and if they are in conflict, only one should ever reach accepted status.

Hah, great concept. Just like the blockchain

@JonathonDunford

I think one important question to answer is how will we be voting on EIPs?
Through a DAO?

Do we need to create a UI for users to interact with our DAO? Currently, it looks like there are CLI methods for voting, but no GUIs. Also, would creating a DAO push us into SEC territory? Will our token be profitable? How do we distribute our coin, how do we verify that a voter is a single entity and not a group of voters, etc, etc

It seems like @JonathonDunford addresses this in Issue 2

[mikeyb]

My Opinions

I am personally a fan of Improvement Proposals and find them to be a healthy way for Features/Fixes to be discussed, planned, developed and implemented. While I think the standard EIP requirements are good. They might be a little strict and not fully fit our needs, but a modified setup would likely work great.

Voting in IPs should probably be based on Github Org members. We could poll a proposal in Discord and if there is overwhelming acceptance of the propsal (say 85%+) then we can transition it into an Accepted state. If there is a majority of acceptance for the proposal, but a split decision (< 85% && > 15%) regarding the implementaion, a disputing party can be given the chance to create a proposal of their own with deviating implementation and voting could resume between the two where you could set a 60% requirement to decide the winning proposal.

Voting options might look like this
1. Accept Proposal
2. Accept Proposal, Disagree Implementation
3. Decline Proposal

IP Types consideration
- Feature
- Fix
- Non-Code (Infrastructure, Coop Admission, Guidelines/nformation)

I do agree with the above sentiment regarding IPs to not be the best method for bootstrapping and should probably be reserved for future features/needs including short and long term.

Since we are not running a public network with global aspects trying to be accomplished, I would suggest having a proposals directory within each repo that it makes sense (larger, multi-dev projects). That way we can confine discussion to the appropriate repo. We could also make use of Projects within that repo to create cards for Accepted proposals. This will maintain a smooth workflow utilizing Issues, Labels, Milestones as well as tracking commits issue and tracking within PRs.

For bootstrapping initial requirements we might consider using a standalone (private) repo that utilizes Project cards for tasks up for consideration and once agreed this is a feature/requirement worth pursuing further, create an Issue to bring a discussion about as well as status tracking.

$0.02

[activescott]

Great input @mikeyb. Thanks !

[activescott]

This is a work in progress in the aip-1 branch at https://github.com/Agorex-io/Proposals/tree/aip-1 . Hope to have the PR submitted with a first complete draft in the next couple days so we can start commenting and iterating there.

[activescott]

This issue is an appropriate place to leave feedback on AIP-1. Especially to express your support for it or your dissenting opinion.

Please discuss detailed feedback on specific lines on the pull request for the Draft at #3 (preferably on the Files changed tab so you can link to specific areas of discussion). This is still an incomplete draft however, so don't feel compelled to get into the details just yet...

[activescott]

@here - I have pushed a complete draft that can be viewed in pull request #3. By "complete" I mean all sections that I intend to have are there. It does not necessarily have the information or clarity that is required. This is where your feedback is welcome! I'm sure there are grammar mistakes, misspellings, or other inaccuracies. Please also express your support for it or call out areas you have a dissenting opinion on so we can incorporate your feedback. Please review quickly and lets try to merge this as a Draft status quickly.

Remember, I am asking to merge this with a Draft status, so this won't make it Final and in this status is non-binding for the Board. We will still welcome feedback while it is in Draft status and are open to incorporating changes.

[activescott]

AIP-1 has been placed in Draft status at https://github.com/Agorex-io/Proposals/blob/master/proposals/aip-1.md We still need your feedback on any suggestions to improve it or even an expression of support (which shows that we are building consensus in the community). Once we feel we have edited it and consensus we'll adjust the status to Final.

[Ebonsignori]

Nice to see you turning this into the thorough document that it needs to be.

##Suggestions
Readability:
To avoid confusion, define a proposal editor earlier in the document, as you refer to the editor(s) and their roles in the document before defining them.

Should not be omitted in this sentance?

Note that personal email addresses in AIPs may not be obscured as a defense against spam harvesters

Perhaps in the “proposal process” or “this process”?

The @Agorex-io/proposal-editors facilitate champions and authors in the process

Make the minimum criteria bullet points?

For an AIP to be merged Draft status it still must meet certain minimum criteria. It must be a clear and complete description of the proposed process or issue. The process or issue must represent a net improvement.

Just a question and not suggestion:
what systematically prevents this?

The AIP editor will not unreasonably deny an AIP in Draft status.