Collaborator role isn't defined properly about project HOT 7 CLOSED

The Moderation guide is again an example of technical depth overwhelming my expectations of the document. I would consider breaking the "Technical HOWTO" that out into COLLABORATION, if it even applies to this project (we will likely be using an opinionated build system like Rampart).

The moderation guide should focus on three sections:

• How to steward third code contributions
• How to steward community discussion
• How to do hardware design by committee (literally)

from project.

I'll echo the sentiment of "Oh, wow, so much text. I don't actually want to read this (and, by extension, feel qualified to help with this project)"

...

One possible workflow on the hardware side is below. I'm not married to it, but it should serve to start the conversation.

• Discussion and initial proposals happen on the forums, if only because GH issues are a little tougher to follow and higher barrier to entry for some people, especially hardware people.
• If the community thinks an idea sounds worth prototyping, a reasonable effort should be made to research what the requirements are and what specific solutions exist. A complete schematic and a "core" parts list are required to advance to the next step.

< Spilt between modules and Tessel platform hardware >

Modules

• A first pass prototype of the hardware should be built and corresponding software (drivers) should be written.
• Once the prototype is completed, the candidate module should be put on the agenda for the next SC meeting by a Collaborator. Discussion topics:
  • Is this something we should roll in as a first party module, or merely an addition to our third party library? Default to 3rd party.
  • If the module will become a 1st party module, what constitutes reasonable reimbursement for the creator in terms of material prototyping costs?
  • What budget, if any, shall be allocated for future development?
• If the concept is to become a first-party module (criteria include "will we sell more than 100 of these per year"?, "is this a problem we should be solving in hardware?", etc.), then the creator of the prototype is reimbursed for prototyping expenses immediately. If it is not to become a first party module, the creator shall not be reimbursed.
• If the hardware is to become a first party module, the SC and the community at large should continue discussion as to if the best possible solution has been chosen. Some combination of the SC member in charge of hardware and the OP will then work to develop the module.

Tessel

• A proposal/spec should be submitted to the SC member responsible for hardware by a Collaborator in the form of an issue on the appropriate repo (presumably the v2 hardware repo?). Realistically, this proposal will be added to a list of RFCs for hardware to be considered...whenever it's time for new hardware, which is something the SC will presumably make a call on.
• When the time comes to develop new hardware, the SC will review the backlog of issues. The SC member in charge of hardware will work to integrate new features as per the result of the discussion.

...So that's a first pass anyway. Takeaways are

• Don't do it all on GH
• Reimbursements for work that becomes 1st party...but how much and how are still totally up in the air. I personally like a percentage cut of ongoing sales paired with reimbursement for material prototyping costs.
• SC decides if something enters the 1st party circle

from project.

Starting with this here for community: https://docs.google.com/document/d/1UXUKes5aDdpQX5To7IWmF9FoYuHxOnEFEc3zmmOROuw/edit

from project.

Working on a redraft using the above conversation. Stepping back to codify the goals of the document.

High-level goals of the collaborator guide:

1. Collaborators are the only people using this guide, doesn't need to explain anything to SC or non-collaborators.
2. Practical & to the point: collaborators use this guide to answer questions & solve problems. No fluff, nothing googleable elsewhere. Links/ToC kind of document, lists preferred over paragraphs.

What kinds of questions are collaborators trying to solve? Design process for this document should include thinking up scenarios collaborators might encounter on Community, Hardware, and Software fronts. Any additional scenarios to consider, e.g. organizational "should this go to the SC?" not covered in the Governance doc?

Scenarios:

• Someone submits a PR to code
• Someone submits an RFC to hardware
• Someone needs help on the forums
• Someone is mean/rude
• Other scenarios? Please comment

Seems like we also need a general workflow, maybe this is related to the RFC thread (#16). Proposing something like this:

1. something is submitted (PR, hardware RFC, someone looking for help on the forums)
2. Within a (week?) a collaborator should be assigned
3. 2 collaborators needed to approve a change to assets/design
4. A change to be open at at least 24h to ensure people can comment

Who makes sure this is working? E.g. collaborators getting assigned to things in a reasonable amount of time

Obviously there are some implicit assumptions in the above, specifically hardware as RFC, pls call me out on that if needed (@ekolker)

from project.

This table of contents:

• Approving or rejecting modifications to assets
  • Software
  • Hardware
• Managing feature requests and RFCs
  • Software
  • Hardware
• Maintaining strong communication with the community
  • Support
  • Outreach
• Ensuring open and respectful discourse

from project.

Currently working here

from project.

All discussion has been moved to the proposal for a guide here.

from project.