From 3498c1913c0662878b1c3dbee6a99a1f47763976 Mon Sep 17 00:00:00 2001 From: jmc <33655003+jmcook1186@users.noreply.github.com> Date: Wed, 5 Jun 2024 13:46:25 +0100 Subject: [PATCH 1/7] feat(lib): add callout to mailing list --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index 707969488..c9b86602a 100644 --- a/README.md +++ b/README.md @@ -93,6 +93,10 @@ Watch this video to learn how to create and run a `manifest`. [![Watch the walk-through video](https://i3.ytimg.com/vi/R-6eDM8AsvY/maxresdefault.jpg)](https://youtu.be/GW37Qd4AQbU) +## Join our mailing list + +We have a public mailing list at if-community@greensoftware.foundation. We send out weekly updates that explains what we've shipped, what we're working on and how you can get involved each week! + ## Contributing From c6770020cc00406083ae0eae26ddecc7891bd45d Mon Sep 17 00:00:00 2001 From: jmc <33655003+jmcook1186@users.noreply.github.com> Date: Wed, 5 Jun 2024 13:49:39 +0100 Subject: [PATCH 2/7] fix(lib): update mailer list --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c9b86602a..68729d1e8 100644 --- a/README.md +++ b/README.md @@ -95,7 +95,7 @@ Watch this video to learn how to create and run a `manifest`. ## Join our mailing list -We have a public mailing list at if-community@greensoftware.foundation. We send out weekly updates that explains what we've shipped, what we're working on and how you can get involved each week! +We have a public mailing list at [if-community@greensoftware.foundation](https://groups.google.com/u/1/a/greensoftware.foundation/g/if-community). We send out weekly updates that explain what we've shipped, what we're working on and how you can get involved each week! ## Contributing From ee7123b85be11176f81d995a87f33c2f0da8e3a3 Mon Sep 17 00:00:00 2001 From: jmc <33655003+jmcook1186@users.noreply.github.com> Date: Wed, 5 Jun 2024 13:50:30 +0100 Subject: [PATCH 3/7] feat(lib): add mailing list to contributing.md --- CONTRIBUTING.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4ac010c51..3974becb0 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -20,11 +20,14 @@ The following document is a rule set of guidelines for contributing. - [Naming conventions](#naming-conventions) - [Documentation](#documentation) - [Writing tests](#writing-tests) + - [How to report issues (bugs)](#how-to-report-issues-bugs) ## What and when to contribute You can contribute anything to the IF, but we are likely to close out unsolicited PRs without merging them. Our issue board is completely open and we have tags (`help-wanted`, `good-first-issue`) to help contributors to choose tasks to work on. We recommend speaking to the core team on Github before starting working on an issue. You can do this by raising an issue or commenting on an existing issue. This helps us to direct your energy in directions that are aligned with our roadmap, prevent multiple people working on the same task, and better manage our board. This all makes it much more likely that your work will get merged. +You can also contribute by participating in discussions on our mailing list at [if-community@greensoftware.foundation](https://groups.google.com/u/1/a/greensoftware.foundation/g/if-community). We send out weekly updates that includes what we've shipped, what we're working on and how you can get involved each week. + ## Reporting bugs We appreciate bug reports! If you experience an issue with IF or one of our plugins, you can report it using our bug reporting template. To do this: From 3c6c7d5ae17785eed618f35b719bcdee767af9f7 Mon Sep 17 00:00:00 2001 From: jmc <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 11 Jun 2024 15:56:32 +0100 Subject: [PATCH 4/7] feat(package): update processes doc with details on SDLC --- github-processes.md | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/github-processes.md b/github-processes.md index 06721b4c6..7c8e9345b 100644 --- a/github-processes.md +++ b/github-processes.md @@ -107,6 +107,7 @@ After a PR has passed triage, it can be assigned to a core team member to review We intend to respond to new PRs and issues within 3 days of the ticket being opened, even if only with a brief message thanking the OP and explaining the triage process. +There may be exceptional instances where bug fixes are prioritized over other ongoing tasks and worked on immediately, before triage. ## Labels @@ -140,3 +141,41 @@ If more than two hotfixes are required on a particular release, the team will ca Hotfixes on release can be merged back into `main` when they have been fully QA tested. We intend for hotfixes to be as infrequent as possible. + + +## Software Development Life Cycle + +Our normal process is to have week-long sprints where we tackle issues that contribute to a larger epic which typically last for 4-6 weeks. + +Our Executive Director and Product owner take responsibility for defining epics. This means they make decisions about how IF should change and translate that into a series of documents that get worked up into tickets for specific tasks. After the initial design, individual tasks are refined by the product owner, which means defining a scope of work and acceptance criteria for each task. + +Refinement is the process of taking a loosely scoped or ambiguous ticket and making it so well-described that anyone could pick it up off the board and produce an equivalent outcome to one of the core team. It's important we do this diligently even if it feels unnecessary or frictionful, because: + +- it keeps us all aligned with the purpose and rationale of individual tasks +- it improves our transparency +- it lowers the barrier to entry for contributors +- it helps us to "measure twice, cut once" and avoid doing work more than once +- it helps us to think together about each issue +- it provides an archive of our thinking that we can go back to in future. + +We use checkboxes for the statement of work and acceptance criteria as this helps to track progress on the task while it is in flight. + +A ticket is considered READY when it has been refined by the product owner. In general, we try to pass the refined ticket to a core developer to review any implementation details. + +We have the `core-only` label that we apply to tasks that are reserved for the core team to work on. Community contributions that cover these tickets are unlikely to get merged unless organized in advance. This is typically for sensitive parts of the core of the IF. + +Epics are also opresented to the community on the IF discussion forum in advance of being worked on in a development sprint. This is to give community contributors a chance to give feedback, suggest course corrections and discuss the changes with the team. These discussions can also lead to community members taking on some of the epic tasks. + +Once the tickets are refined they get prioritized and assigned during our development sprints. There is a pre-sprint prioritization call between the project sponsor, owner and manager to determien the priorities for each sprint, then a sprint planning meeting where the tasks are assigned and sized. + +### Overview of development practises + +| Stage | Participants | Inputs | Outputs | Overview | +| ----------------------------------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 1. Initiation | Sponsor and Product Owner | Problem Statement and Objectives | Action Plan | In this phase, the team identifies a specific job-to-be-done or problem, develops a high-level vision for a solution, and outlines a preliminary task breakdown. | +| 2. Backlog | Product Owner | Breakdown of Epic or Milestone Tasks | An issue for each high-level task detailing the What and Why, along with a link to its parent epic | In this phase, each task from the epic or milestone is incorporated into the backlog (labeled as 'draft'), setting the context effectively. | +| 3. Design | Sponsor and Product Owner | What and Why, link to parent Epic Priority, Preliminary Acceptance Criteria and outline of work scope | In this phase, preliminary acceptance criteria are documented as a foundation for further refinement. | +| 4. Refinement Product Owner, Dev and QA (where applicable) | Preliminary Acceptance Criteria and outline of work scope | Comprehensive scenarios for Acceptance Criteria, confirmed work scope, and size | In this phase, engineers review the desired outcomes to ensure technical feasibility, clarify doubts, and solidify their understanding. They also estimate the required effort. Following this review, the issue is deemed Ready for implementation. | +| 5. Implementation | Dev and QA (where applicable) | A comprehensive set of scenarios for Acceptance Criteria and a confirmed Scope of Work. | A Pull Request (PR) including Unit Tests that pass and manifest files for automated testing, Technical documentation | In this phase, engineers execute the solution and review PRs. They also record a demo to demonstrate that it meets the acceptance criteria. | +| 6. UAT | Product Owner and Sponsor (if applicable) | Working feature and Acceptance Criteria | TBC | In this phase, the Product Owner verifies that the implementation matches the design by reviewing a demonstration of the work completed. | +| 7. Rollout \Product Owner, Sponsor and Marketing (if applicable) | Demos, Technical Documentation | TBC | In this phase, the Product Owner ensures that the community is prepared for the upcoming change. This preparation includes updates to the change log, project announcements, revisions to documentation, marketing efforts, and more. | From 944f053ceee5e093b2701c07480f7164841b2626 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 11 Jun 2024 17:25:06 +0100 Subject: [PATCH 5/7] Update github-processes.md Signed-off-by: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> --- github-processes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/github-processes.md b/github-processes.md index 7c8e9345b..81f2301d5 100644 --- a/github-processes.md +++ b/github-processes.md @@ -178,4 +178,4 @@ Once the tickets are refined they get prioritized and assigned during our develo | 4. Refinement Product Owner, Dev and QA (where applicable) | Preliminary Acceptance Criteria and outline of work scope | Comprehensive scenarios for Acceptance Criteria, confirmed work scope, and size | In this phase, engineers review the desired outcomes to ensure technical feasibility, clarify doubts, and solidify their understanding. They also estimate the required effort. Following this review, the issue is deemed Ready for implementation. | | 5. Implementation | Dev and QA (where applicable) | A comprehensive set of scenarios for Acceptance Criteria and a confirmed Scope of Work. | A Pull Request (PR) including Unit Tests that pass and manifest files for automated testing, Technical documentation | In this phase, engineers execute the solution and review PRs. They also record a demo to demonstrate that it meets the acceptance criteria. | | 6. UAT | Product Owner and Sponsor (if applicable) | Working feature and Acceptance Criteria | TBC | In this phase, the Product Owner verifies that the implementation matches the design by reviewing a demonstration of the work completed. | -| 7. Rollout \Product Owner, Sponsor and Marketing (if applicable) | Demos, Technical Documentation | TBC | In this phase, the Product Owner ensures that the community is prepared for the upcoming change. This preparation includes updates to the change log, project announcements, revisions to documentation, marketing efforts, and more. | +| 7. Rollout | Product Owner, Sponsor and Marketing (if applicable) | Demos, Technical Documentation | TBC | In this phase, the Product Owner ensures that the community is prepared for the upcoming change. This preparation includes updates to the change log, project announcements, revisions to documentation, marketing efforts, and more. | From 2fee65eb30db94d26cca4bde69c30ec7cc07f175 Mon Sep 17 00:00:00 2001 From: jmc <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 11 Jun 2024 20:11:14 +0100 Subject: [PATCH 6/7] fix(package): bump braces version to address high severity vuln in npm audit report --- package-lock.json | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/package-lock.json b/package-lock.json index 638b4e48a..a52e10aa3 100644 --- a/package-lock.json +++ b/package-lock.json @@ -3004,11 +3004,12 @@ } }, "node_modules/braces": { - "version": "3.0.2", + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz", + "integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==", "dev": true, - "license": "MIT", "dependencies": { - "fill-range": "^7.0.1" + "fill-range": "^7.1.1" }, "engines": { "node": ">=8" @@ -5003,9 +5004,10 @@ } }, "node_modules/fill-range": { - "version": "7.0.1", + "version": "7.1.1", + "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz", + "integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==", "dev": true, - "license": "MIT", "dependencies": { "to-regex-range": "^5.0.1" }, @@ -6321,8 +6323,9 @@ }, "node_modules/is-number": { "version": "7.0.0", + "resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz", + "integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==", "dev": true, - "license": "MIT", "engines": { "node": ">=0.12.0" } @@ -11087,8 +11090,9 @@ }, "node_modules/to-regex-range": { "version": "5.0.1", + "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz", + "integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==", "dev": true, - "license": "MIT", "dependencies": { "is-number": "^7.0.0" }, From c4f15c95bb02a958d530f72e796a67cf3514178d Mon Sep 17 00:00:00 2001 From: Release commit workflow Date: Thu, 13 Jun 2024 15:09:31 +0000 Subject: [PATCH 7/7] =?UTF-8?q?chore(release):=20v0.4.0=20=E2=9C=A8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- package-lock.json | 4 ++-- package.json | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/package-lock.json b/package-lock.json index a52e10aa3..1c2c47735 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,12 +1,12 @@ { "name": "@grnsft/if", - "version": "0.3.4", + "version": "0.4.0", "lockfileVersion": 3, "requires": true, "packages": { "": { "name": "@grnsft/if", - "version": "0.3.4", + "version": "0.4.0", "license": "MIT", "dependencies": { "@commitlint/cli": "^18.6.0", diff --git a/package.json b/package.json index 60e33dc0f..c6db34155 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,7 @@ { "name": "@grnsft/if", "description": "Impact Framework", - "version": "0.3.4", + "version": "0.4.0", "author": { "name": "Green Software Foundation", "email": "info@gsf.com"