Propose rough draft on governance

[F-said]

What needs documentation and what will each item entail?

• Initial governance structure and credit assignment standards established

[F-said]

Frederick P. Brooks Jr. Architecture, Democracy, and System Design. The Mythical Man-Month, 1995, pp. 41 - 50

Challenges

• How do you maintain "conceptual unity" through iterations of developers (implementers) and researchers (architects)?
• What is the concept of PEPPER? "A framework of EEG data preprocessing features designed for reproducibility, interchangeability, and ease-of-use."
• Therefore any improvements must reflect this set of ideas outlined by the architects of the project
  • interchangeable
  • easy to use, that is, a light background in Python is sufficient
  • reproducible
• But how can this outlining of specifications be brought in line with a project that has its future outlined in open-source collaboration, something that must be fundamentally unrestricted?

Proposed Solution

Separation of architecture (research, syntax, documentation) from implementation (coding) ensures conceptual integrity on a large scale.

Questions to Solution

1. This can be thought of as an "aristocracy" where the meticulous planning is reserved for a section of the members, and the developers being the cogs.
2. Specification may be "too rich in function" and fail to reflect practical development outcomes.
3. What is left for the implementers to do if the generation of "thought-stuff" behind the software is out of their decision?

Answers

1. In return, the integrity of the project is maintained. Good ideas that sprout from this project, but do not fit in its design principles can be branched off to separate software, but must be omitted from the project itself.
   • W/o architectural constraints, implementers will have to act as architects for the underlying principle of the software while they develop, resulting in "uncertain" software.
2. Consistent discussion between architects and implementers will allow a possible reframing of spec.
3. Development requires its own creative effort to implement the outlined concepts, "form is liberating."

Form of this solution in PEPPER

• Perhaps the initial direction for this project can be comprehensively outlined in our documentation, manuals, automatic tests, and containers.
• The architecture, while initially composed by the base researchers, will exist external to the users and be reinforced through automatic tests and checks.
• Since this will be an open-source project, this established architecture that exists externally will be closed for modification (at the risk of PEPPER going away from its intended purpose), but open for extension.
  • That is, as development progresses, architecture could be expanded to relevant and new features, but must omit non-relevant features as outlined by the docs/tests/etc.
• Furthermore, as this will be open-source, any contribution that comes in the form of expansion of architecture or changes in implementation will not be held to a vote but rather through the fork and branch model.
  • for example, an external contributor might take this route to contribution
    1. Create issue A
    2. Fork and branch with issue A as motivation
    3. Commit changes
    4. Propose PR to collective
    5. Multiple outcomes
  • If PR does not violate the preconditions of the architecture, then it is accepted
  • PR violates preconditions and is deleted by OG author
  • PR violates preconditions and OG author is free to continue their own development of this feature

[F-said]

Questions

• Who approves PR's?
• Who can become a maintainer?
• Is a maintainer different from an architect?
• Who can become an architect?

Next Actions

• Codify this idea
• Simplify
• Propose idea in README