Merge branch 'master' into nrd_kernels

text/0001-rfc-process.md

@@ -35,7 +35,7 @@ Some changes do not require an RFC:
 
 If you submit a pull request to implement a new feature without going through the RFC process, it may be closed with a polite request to submit an RFC first.
 
-### Sub-team specific guidelines
+### Team specific guidelines
 
 _To be added here once available._
 
@@ -47,10 +47,9 @@ A hastily-proposed RFC can hurt its chances of acceptance. Low quality proposals
 Although there is no single way to prepare for submitting an RFC, it is generally a good idea to pursue feedback from other project contributors
 beforehand, to ascertain that the RFC may be desirable; having a consistent impact on the project requires concerted effort toward consensus-building.
 
-Ways to prepare and pave the way for writing and submitting an RFC include discussing the topic or posting "pre-RFCs" to our [forum](https://grin-forum.org) for feedback.
+Ways to prepare and pave the way for writing and submitting an RFC include discussing the topic or posting "pre-RFCs" to our [forum](https://forum.grin.mw) for feedback.
 
-As a rule of thumb, receiving encouraging feedback from long-standing project
-contributors, and particularly members of the relevant sub-team (if applicable) is a good indication that the RFC is worth pursuing.
+As a rule of thumb, receiving encouraging feedback from long-standing project contributors, and particularly members of the relevant team (if applicable) is a good indication that the RFC is worth pursuing.
 
 ## Process description
 [process-description]: #process-description
@@ -71,15 +70,15 @@ In order to make a "substantial" change to Grin, one must first get an RFC merge
 
 #### Draft
 
-* Each pull request will be labeled with the most relevant sub-team, which will lead to it being triaged by that team and is assigned a shepherd from this team. The shepherd ensures the RFC progresses through the process and that a decision is reached, but they themselves do not make this decision.
+* Each pull request will be labeled with the most relevant team, which will lead to it being triaged by that team and is assigned a shepherd from this team. The shepherd ensures the RFC progresses through the process and that a decision is reached, but they themselves do not make this decision.
 * As the author, you build consensus and integrate feedback. RFCs that have broad support are much more likely to make progress than those that don't receive any comments. They are encouraged to reach out to the RFC shepherd in particular to get help identifying stakeholders and obstacles.
-* The relevant sub-team discuss the RFC pull request, as much as possible in the comment thread of the pull request itself. Offline discussion will be summarized on the pull request comment thread.
+* The relevant team discuss the RFC pull request, as much as possible in the comment thread of the pull request itself. Offline discussion will be summarized on the pull request comment thread.
 * RFCs rarely go through this process unchanged, especially as alternatives and drawbacks are shown. As an author you can make edits, big and small, to the RFC to clarify or change the design,but make changes as new commits to the pull request, and leave a comment on the pull request explaining your changes. Specifically, do not squash or rebase commits after they are visible on the pull request.
 
 #### Final Comment Period (FCP)
 
-* At some point, a member of the sub-team will propose a "motion for final comment period" (FCP), along with a *disposition* for the RFC (merge, close, or postpone).
-* This step is taken when enough of the tradeoffs have been discussed that the sub-team is in a position to make a decision. That does not require consensus amongst all participants in the RFC thread (which is usually impossible). However, the argument supporting the disposition on the RFC needs to have already been clearly articulated, and there should not be a strong consensus *against* that position outside of the sub-team. Sub-team members use their best judgment in taking this step, and the FCP itself ensures there is ample time and notification for stakeholders to push back if it is made prematurely.
+* At some point, a member of the assigned team will propose a "motion for final comment period" (FCP), along with a *disposition* for the RFC (merge, close, or postpone).
+* This step is taken when enough of the tradeoffs have been discussed that the team is in a position to make a decision. That does not require consensus amongst all participants in the RFC thread (which is usually impossible). However, the argument supporting the disposition on the RFC needs to have already been clearly articulated, and there should not be a strong consensus *against* that position outside of the team. Team members use their best judgment in taking this step, and the FCP itself ensures there is ample time and notification for stakeholders to push back if it is made prematurely.
 * For RFCs with lengthy discussion, the motion to FCP is usually preceded by a *summary comment* trying to lay out the current state of the discussion and major tradeoffs/points of disagreement.
 * The FCP lasts ten calendar days, so that it is open for at least 5 business days. It is also advertised widely (i.e. in [Grin News](https://grinnews.substack.com)). This way all stakeholders have a chance to lodge any final objections before a decision is reached.
 * In most cases, the FCP period is quiet, and the RFC is either merged or closed. However, sometimes substantial new arguments or ideas are raised, the FCP is canceled, and the RFC goes back into draft mode.
@@ -96,13 +95,13 @@ In order to make a "substantial" change to Grin, one must first get an RFC merge
 * Furthermore, the fact that a given RFC has been accepted and is "active" implies nothing about what priority is assigned to its implementation, nor does it imply anything about whether a developer has been assigned the task of implementing the feature.
 * While it is not necessary that the author of the RFC also write the implementation, it is by far the most effective way to see an RFC through to completion: authors should not expect that other project contributors will take on responsibility for implementing their accepted feature.
 * Modifications to "active" RFCs can be done in follow-up pull requests. We strive to write each RFC in a manner that it will reflect the final design of the feature; but the nature of software development means that we cannot expect every merged RFC to actually reflect what the end result will be at the time of implementation.
-* In general, once accepted, RFCs should not be substantially changed. Only very minor changes should be submitted as amendments. More substantial changes should be new RFCs, with a note added to the original RFC. Exactly what counts as a "very minor change" is up to the sub-team to decide; check sub-team specific guidelines for more details.
+* In general, once accepted, RFCs should not be substantially changed. Only very minor changes should be submitted as amendments. More substantial changes should be new RFCs, with a note added to the original RFC. Exactly what counts as a "very minor change" is up to the team to decide; check team specific guidelines for more details.
 
 #### Postponed
 
 * Some RFC pull requests are tagged with the "postponed" label when they are closed (as part of the rejection process).
 * An RFC closed with "postponed" is marked as such because we want neither to think about evaluating the proposal nor about implementing the described feature until some time in the future, and we believe that we can afford to wait until then to do so.
-* Postponed pull requests may be re-opened when the time is right. We don't have any formal process for that, you should ask members of the relevant sub-team.
+* Postponed pull requests may be re-opened when the time is right. We don't have any formal process for that, you should ask members of the relevant team.
 * Usually an RFC pull request marked as "postponed" has already passed an informal first round of evaluation, namely the round of "do we think we would ever possibly consider making this change, as outlined in the RFC pull request, or some semi-obvious variation of it." (When the answer to the latter question is "no", then the appropriate response is to close the RFC, not postpone it.)
 
 #### Closed
@@ -113,7 +112,7 @@ In order to make a "substantial" change to Grin, one must first get an RFC merge
 
 In the spirit of the proposed process itself, a future "substantial" overhaul to the RFC process should be opened as a new RFC rather than making edits to this RFC. Minor changes can be made by opening pull requests against this document.
 
-As the RFC process is something that should be consistent across all sub-teams and the project as a whole, changes to the process fall under Core's remit. As they evaluate proposals to modify the process, they are expected to consult with sub-teams, and other stakeholders using or being affected by the process.
+As the RFC process is something that should be consistent across all teams and the project as a whole, changes to the process fall under Core's remit. As they evaluate proposals to modify the process, they are expected to consult with teams, and other stakeholders using or being affected by the process.
 
 ## Drawbacks
 [drawbacks]: #drawbacks

text/0002-grin-governance.md

@@ -12,7 +12,7 @@ Evolve Grin's governance:
 - Define general community principles;
 - Convert council into core team and define its responsibilities and processes;
 - Introduce RFC process;
-- Introduce self-governing sub-teams that steward and guide work in each of their focus areas.
+- Introduce self-governing teams that steward and guide work in each of their focus areas.
 
 # Motivation
 [motivation]: #motivation
@@ -70,11 +70,11 @@ The core team leads the wider Grin project as a whole. In particular:
 
 * **Sets overall direction and vision.** Values and philosophies. Steering towards use cases and targets.
 * **Sets priorities and plans releases.** Maintains high level planning, roadmaps, focus areas, decides on pace and the release schedule.
-* **Work on broader, cross-sectional issues.** What falls in-between sub-teams, taking a global view. 
-* **Adds and removes sub-teams.** While proposals for new sub-teams can come from anywhere, the core team is responsible to ensure structures are productive and make sense.
-* **Appoints initial sub-team leadership.** Once a new sub-team is established, core appoints a leader that has the responsibility to grow the sub-team.
+* **Work on broader, cross-sectional issues.** What falls in-between teams, taking a global view. 
+* **Adds and removes teams.** While proposals for new teams can come from anywhere, the core team is responsible to ensure structures are productive and make sense.
+* **Appoints initial team leadership.** Once a new team is established, core appoints a leader that has the responsibility to grow the team.
 * **Responsible for security.** Handles disclosures, vulnerabilities, audits, processes. 
-* **Handles multi-sig keys and takes high level spending decisions.** Spending proposals can be made by anyone, and sub-teams can have their own own budgets to deal with as they please.
+* **Handles multi-sig keys and takes high level spending decisions.** Spending proposals can be made by anyone, and teams can have their own own budgets to deal with as they please.
 
 #### Organization & Processes
 
@@ -87,26 +87,26 @@ The core team leads the wider Grin project as a whole. In particular:
 - The term of core members is currently undefined but may change in the future.
 - A core member can resign by notifying the rest of the team.
 - If unreachable for 30 days without any news, a core member can be removed through a core decision.
-- The core team *does not* make rulings on RFCs of other sub-teams, although individual team members might also participate in the discussions of sub teams or be members of those teams.
+- The core team *does not* make rulings on RFCs of other teams, although individual team members might also participate in the discussions of sub teams or be members of those teams.
 - Meeting notes should be published and made transparent to the community on a regular basis. 
 
 ### RFC process
 
 An RFC is a Request For Comments document, outlining a proposed improvement or design change to an area of Grin. The exact specifics for the template is TBD. They are kept in their own dedicated repo and need to be accepted before a pull request is merged. Their purpose is to outline a standardized way of making proposals and allow the community to discuss and evaluate whether something is worth doing. Having an RFC accepted means that there's support "in theory" for the suggestion. It does not mean that a change becomes implemented automatically or in the exact way it is proposed, it is high-level design. The work still needs to be carried out. Accepted RFCs guide the broader planning work.
 
-### Sub-teams
+### Teams
 
 #### Overview 
 
-Sub teams are groups organized around specific areas or knowledge fields. They are responsible for these areas, but do not do all the work. Anyone can contribute anywhere, and do not need to hold a particular title to do so. 
+Teams are groups organized around specific areas or knowledge fields. They are responsible for these areas, but do not do all the work. Anyone can contribute anywhere, and do not need to hold a particular title to do so. 
 
-Rather, sub-teams work on policies, processes, and workflows for their specific areas, as required. They are in charge of the RFC process in their specific field: They determine what requires an RFC in their area, they assign RFC shepherds that guide an RFC through its various stages and ensures the right stakeholders become aware of it and solicit their feedback. Ultimately, sub-teams decide whether an RFC in their area should be accepted or rejected. They are responsible to ensure that each RFC in their area has a tracked status, and that they progress towards an outcome.
+Rather, teams work on policies, processes, and workflows for their specific areas, as required. They are in charge of the RFC process in their specific field: They determine what requires an RFC in their area, they assign RFC shepherds that guide an RFC through its various stages and ensures the right stakeholders become aware of it and solicit their feedback. Ultimately, teams decide whether an RFC in their area should be accepted or rejected. They are responsible to ensure that each RFC in their area has a tracked status, and that they progress towards an outcome.
 
-Sub-teams self-organize, but should be inclusive and adhere to community values. They should have a leader, often this leader may be part of the core team. They determine how members get added to the team. They should include area experts, and stakeholders. The decision making process should be consensus-seeking where possible.
+Teams self-organize, but should be inclusive and adhere to community values. They should have a leader, often this leader may be part of the core team. They determine how members get added to the team. They should include area experts, and stakeholders. The decision making process should be consensus-seeking where possible.
 
-Sub-teams can be broken down into smaller working groups or sub-teams, permanent or temporary, as required and is seen necessary for them to be productive.
+Teams can be broken down into smaller working groups or teams, permanent or temporary, as required and is seen necessary for them to be productive.
 
-Each sub-team has a dedicated section on the forum, they should meet regularly, and keep some notes on what was covered and decided. Decisions do not need to happen in meetings, and could for example be handled asynchronously or in the RFC process.
+Each team has a dedicated section on the forum, they should meet regularly, and keep some notes on what was covered and decided. Decisions do not need to happen in meetings, and could for example be handled asynchronously or in the RFC process.
 
 Meeting notes should be published and made transparent to the community on a regular basis. 
 
@@ -126,22 +126,22 @@ In addition to Core team, the following teams are proposed to be created initial
 
 * **Fundraising.** Sponsorships, donations, activities to increase project funds.
 
-* **Moderation.** Code of conduct, handles violations, across all areas of the project.  To avoid biases and conflicts of interest, this sub-team _does not_ contain any member of the core team.
+* **Moderation.** Code of conduct, handles violations, across all areas of the project.  To avoid biases and conflicts of interest, this team _does not_ contain any member of the core team.
 
 ### In case of conflicts, disagreement, or dissent
 
-Sub-teams are created and appointed by the core, and core can decide to re-organize team structures and shut down dysfunctional teams. This is a "nuclear" option, such decisions should not be taken lightly. The repercussions of such actions can be worse than the initial situation.
+Teams are created and appointed by the core, and core can decide to re-organize team structures and shut down dysfunctional teams. This is a "nuclear" option, such decisions should not be taken lightly. The repercussions of such actions can be worse than the initial situation.
 
-In practice, core team members might be engaging with sub-teams as individual contributors. It is however not expected that "the core team" will become involved in the responsibilities of individual sub-teams. Core sets the overall direction for the project, but should not micro manage sub-teams as this defeats the entire purpose of having these teams in the first place.
+In practice, core team members might be engaging with teams as individual contributors. It is however not expected that "the core team" will become involved in the responsibilities of individual teams. Core sets the overall direction for the project, but should not micro manage teams as this defeats the entire purpose of having these teams in the first place.
 
-If there are conflicts within sub-teams, these should ideally be resolved within the sub-teams themselves. If this is not possible and there's contentious disagreements that need outside arbitration, sub-teams can invite core or another sub-team to become involved.
+If there are conflicts within teams, these should ideally be resolved within the teams themselves. If this is not possible and there's contentious disagreements that need outside arbitration, teams can invite core or another team to become involved.
 
 # Drawbacks
 [drawbacks]: #drawbacks
 
 - Adds a lot more structure. This might create overhead.
 - Could lead to infighting and conflict between teams.
-- Could lead to situations where one sub-team does work that conflicts with other sub-teams, "left hand not talking to the right".
+- Could lead to situations where one team does work that conflicts with other teams, "left hand not talking to the right".
 
 
 # Rationale and alternatives
@@ -167,7 +167,7 @@ Far too many to all be listed here, but here are some:
 # Future possibilities
 [future-possibilities]: #future-possibilities
 
-- Introduce more sub-teams
+- Introduce more teams
 - Introduce an electorate
 - Introduce terms
 - Define firmer structures and organizational rules