G7 Product Development Guidelines

The G7 Product Development Guidelines establishes standards, conventions and guidelines for the rapid prototyping of opensource projects.

Vision

G7 believes that all opensource products brought from concept to scale exist in 4 opensource states. Each state is sharable and can add value to the opensource community.

• Idea - An idea should be described in a way that it can be shared and a specification created from it.
• Specification - An product spec written in a way that it can be shared and that something can be built from it.
• Prototype - An MVP that can be shared and provides a foundation for a working product.
• Production - A working product that can be shared and that can be used with very little additional work.

Goals:

• Establish predictable, repeatable process for which an idea can be chosen for development into an opensource specification.
• Establish predictable, repeatable process for creating opensource specifications from an idea.
• Establish predictable, repeatable process for creating opensource prototypes or MVP's from the specifications.
• Establish predictable, repeatable process for the development of prototypes or MVP's into production grade products.

The Idea: (this will never work)

G7 team actively engages with community members, developers, domain experts and industry insiders to understand what products, tooling, systems or services are needed within various ECO systems.

G7 team aggregates and distills that feedback into products that can be rapidly converted into an opensource specification.

The process of how an idea gets converted into a specification is as follows:

• A community member (any community) may bring the G7 team an idea or a G7 team member may reach out to a community member and inquire about an idea.
• G7 team member(s) bring idea to entire G7 team for discussion concerning viability.
• G7 team further distills the idea into a potential MVP and discusses MVP with the idea's origin / author.
• MVP is presented to the G7 community for a vote.
• MVP is moved to the spec pipeline if majority votes yes on the idea.

IDEA SUBMISSION PROCESS and EXAMPLES

The Specification: (hope someone build this)

All ideas that have been approved by the G7 community are placed into an SRS (ISO/IEC/IEEE 29148:2018 Software Requirements Specification) pipeline and placed into the development calendar. SRS development roadmap is coordinated with the idea author.

The SRS with be developed, in conjunction with the idea author, in the following manner:

• Create PUBLIC G7 repo, add SRS template and README. Sample SRS template
• Complete SRS with the idea author using the SRS template.
• The SRS should be as complete as possible. It should include diagrams, user stories and detailed feature descriptions.
• The SRS should is considered complete when any competent developer can build an MVP from the SRS.

Once the SRS is complete and the author has been properly attributed, the SRS is brought back to the G7 community for a vote on whether a protoype should be created from the SRS by the G7 team or by a dev shop employed by the G7 teams.

If G7 community votes NO, the existence of the SRS is advertised to all communities G7 belongs to through our community leaders, is advertised via the official G7 Twitter account and is advertised in the G7 blog.

If G7 community votes YES, the SRS is added to the development pipeline and placed into the development calendar. The dev calendar is coordinated with the idea author.

The Prototype: (embarrassed this actually works)

All products that are specced-out and that have been added to the development pipeline will be assigned to a specific G7 team member, community member or contractor lead as the single point of contact for that project. That person will act as the PM (project manager) for that project until it reaches an MVP status.

The PM may or may not work directly on the project. The PM is primarily responsible for converting the spec into a project workflow, ensuring the project has the resources it needs, ensuring the project remains on schedule and communicating with the idea author.

Once the product has reached an MVP state and the author has been properly attributed, the project is brought back to the G7 community for a vote on whether a production grade version of the product should be created.

If G7 community votes NO, the existence of the MVP is advertised to all communities G7 belongs to through our community leaders, is advertised via the official G7 Twitter account and is advertised in the G7 blog.

If G7 community votes YES, the MVP is added to the development pipeline and placed into the development calendar. The dev calendar is coordinated with the idea author.

The Product: (into the wild)

TODO