Proposals

This repo is for determing solutions to large initiatives that require significant preparation, discussion, and planning, particularly those with multiple divirgent potential solutions. The process:

0. When in doubt, ping @grin

If you're blocked, have questions, or are unsure about how to proceed, message @grin on Slack.

1. Create a Preliminary Issue

The issue description should contain the following items:

• Owner: who is in charge of moving the issue forward? Include contact info (email, slack, discord, etc)
• Preliminary Problem Statement: what problem will this proposal be solving? A good problem statement is the most important part of any proposal. The problem statement created at this time is preliminary, the first job of the problem solving team will be to agree on a well-defined problem statement.
• Preliminary Requirements: what attributes or properties must a solution to this problem have?
• Preliminary User Stories. A few informal, real-world examples of the problem in natural language.
• If you desire, or if you're doing this for the first time, run your issue by Jeremy or Grin.
• Tag this issue "preliminary".

2. Team Formation

1. Send an email to team@lbry.io announcing the formation of a project group. Also mention it on Slack. Ask people to let you know via email or Slack if they are interested in joining.
2. Collect the interested people in a Slack channel.
3. Create an email alias for the group if you desire one, or ask @finer9 to do this for you.
4. Poll and/or set a first meeting time for the group.
5. On the first meeting, set a regular meeting interval (most likely every 2-6 weeks).

3. Problem Consensus

The first step of every team is to make a strong effort on building a consensus problem statement and user stories.

Ideally, this should be completed on the first meeting. If issues are raised on this meeting that require further research or discovery to form the problem statement, these tasks should be assigned. Then, another meeting should be had after those tasks are completed. This process should be repeated until the problem statement and user stories are well formed.

If there is no consensus on the problem and no further research or discovery actions, disagreements on the problem should be noted. Maybe the issue needs to be split into two or more separate problems.

At this point, the issue should include the well-defined problem statement, well-defined requirements, and well-defined user stories, be tagged "prepared", and converted to an epic.

At times, a problem may have trade-offs between requirements (e.g. it may not be possible for a solution to be both decentralized and performant). In these cases, this should be noted on the issue.

A tentative deadline should be set for submitting proposed solutions.

4. Solutions

After the problem is prepared, anyone can submit a proposed solution. Members of the problem group may submit solutions on their own, form subgroups to work on different solutions, or all work together on separate solutions.

When a proposal is ready to accept solutions, announce this fact to everyone.

Proposed solutions should include:

• simple summary (non-technical)
• solution description (technical)
• pros, cons, how cons might be mitigated
• assumptions and risks
• test cases
• implementation (not strictly necessary, but even rough code is very helpful)

Proposed solutions should be attached to the epic representing the problem and be tagged "solution".

As soon as a proposed solution is in a state where feedback can be given, it should be shared with the rest of the group either via chat or email. All members of the group are encouraged to collaborate on others solutions, both in terms of pointing out problems and improvements.

Remember: the goal is not to have your own solution "win", but to find the best overall solution.

5. Selecting a Solution

After the solution deadline and group members have submitted potential solutions, a meeting should be set to present all potential solutions in real time to all group members, as well as the CTO and CEO.

On or shortly after this meeting, one of two things will happen:

1. A decision will be made as to which solution to persue. Then the solution will be turned into an epic and the typical epic process for managing large, cross-team issues will be followed.
2. The process will move backwards some number of steps. Either the problem or solutions will be requested to be refined further.