Feature Description:

We've recently implemented significant changes to our company structure and workflows. This repository should be updated to reflect the latest changes in pod structure, standups, and technical workflow.

This is an epic and should be flushed out accordingly.

User stories:

• As a community documentation contributor I would like to have updated issue templates for the drud/community repository. #30
• As a communty member, I want to understand how DDEV manages work from idea to delivery.
• As a communty member, I want to understand the concept pods.
• As a pod member, I want to understand my roles and responsibilities.
• As a pod lead, I want to understand my roles and responsibilites.
• As a pod project manager, I want to understand my roles and responsibilites.
• As a product manager, I want to understand my roles and responsibilites as they relate to moving ideas into deliveries.
• As a project manager, I want to understand my roles and responsibilites necessary to support pods.
• As a praticipant in standups I would like to know how to participate.

Acceptance criteria:

• Updated github templates are in place for drud/community
• Current documentation is updated to satisfy the user stories on this epic.
• Readthedocs is generating documentation instead of github - #35

Related links or issues:

• ddev-webserver image build and start
• buildpacks demo and notes in this folder:
• State of things today: Live | Local

Definition of Ready Checklist:

• User-facing feature: provides story or A/C in Gherkin format, or
• Architectural feature: provides technical A/C
• Dependencies identified
• Sized by team

R^{Product Owner} A^{Scrum Master} C^{Eng. Lead} I^Team

Definition of Done Checklist:

• Acceptance Criteria tested and passing
• Deployed on test environment
• QA performed & issues resolved
• Unit test and E2E coverage updated (if applicable)
• Builds without errors
• Internal documentation updated (if required)

R^{Eng. Lead, Team} A^{Scrum Master} CI^{Product Owner}

Feature Description:

As a DDEV engineer I want to understand how to move my code from the lower environments into production. The current section on the release process is spartan and needs to be flushed out. It's probable it should be broken out into it's own section and enhanced with active current conversations like etiquette.

User stories:

• As an engineer in the organization I need concise documentation on how to release my code to all environments.

Acceptance criteria:

• Documentation outlines release process steps from beginning to end.
• Documentation outlines where to go to obtain help if a problem surfaces.
• Documentation outlines management of notifications through statuspage

Related links or issues:

• https://github.com/drud/handbook/blob/master/docs/engineering/development.md#release-process
• https://github.com/drud/ddev-live/blob/master/docs/adr/0008-infrastructure-release-pattern.md
• https://github.com/drud/ddev-live/blob/master/docs/adr/0008-infrastructure-release-pattern.md

Definition of Ready Checklist:

• User-facing feature: provides story or A/C in Gherkin format, or
• Architectural feature: provides technical A/C
• Dependencies identified
• Sized by team

R^{Product Owner} A^{Scrum Master} C^{Eng. Lead} I^Team

Definition of Done Checklist:

• Acceptance Criteria tested and passing
• Deployed on test environment
• QA performed & issues resolved
• Unit test and E2E coverage updated (if applicable)
• Builds without errors
• Internal documentation updated (if required)

R^{Eng. Lead, Team} A^{Scrum Master} CI^{Product Owner}

Feature Description:

Write up a document on how to improve the ADR process in 1 hr timebox and socialize (Dylan, Nathan, Nic)

Framing Questions: What’s the problem, how do we know it’s a problem, how do we know we solved it?

User stories:

As an author of ADRs, I'd like to avoid having to write long winded ADRs when what I want is an initial conversation
As an author of ADRs, I'd like to write them when we’ve actually made a decision
As an author of ADRs, I'd like to avoid writing an ADR when it’s actually technical documentation that is needed

Acceptance criteria:

• Live sync discussion on current state and potential solutions.
• Create the scope of the spike work.
• Record / Memorialize decision-making process

Related links or issues:

Definition of Ready Checklist:

• User-facing feature: provides story or A/C in Gherkin format, or
• Architectural feature: provides technical A/C
• Dependencies identified
• Sized by team

R^{Product Owner} A^{Scrum Master} C^{Eng. Lead} I^Team

Definition of Done Checklist:

• Acceptance Criteria tested and passing
• Deployed on test environment
• QA performed & issues resolved
• Unit test and E2E coverage updated (if applicable)
• Builds without errors
• Internal documentation updated (if required)

R^{Eng. Lead, Team} A^{Scrum Master} CI^{Product Owner}

Feature Description:

Update the community docs to reflect our current scrum and sprint processes

User stories:

As a new member of the DDEV Community, I'd like to have documentation to refer to understand how the team runs its sprints

Acceptance criteria:

• Migrate and update docs from notion
• Integrate new process recs

Related links or issues:

https://github.com/drud/community/blob/dev/docs/project-management/scrum.md --> edit directly and it will deploy to https://handbook.ddev.com/en/dev/project-management/scrum/docs/project-management/scrum.md

Definition of Ready Checklist:

• User-facing feature: provides story or A/C in Gherkin format, or
• Architectural feature: provides technical A/C
• Dependencies identified
• Sized by team

R^{Product Owner} A^{Scrum Master} C^{Eng. Lead} I^Team

Definition of Done Checklist:

• Acceptance Criteria tested and passing
• Deployed on test environment
• QA performed & issues resolved
• Unit test and E2E coverage updated (if applicable)
• Builds without errors
• Internal documentation updated (if required)

R^{Eng. Lead, Team} A^{Scrum Master} CI^{Product Owner}

The roles and responsibilities of the participants in our workflow should be identified and documented so that expectations between roles can be understood.

Documentation in this repository should be updated to describe the responsibilities for each of the following roles:

• Product Owner
• Release Manager
• Drud Maintainer
• Drud Contributor
• ???

When complete, the documentation should provide a clear picture of how each role interacts with our workflow.

Related links or issues:

• example https://github.com/kubernetes/community/blob/master/governance.md#project-roles
• example https://github.com/docker/docker/blob/master/MAINTAINERS
• relevant conversation https://github.com/drud/general/issues/3#issuecomment-291197831

What happened (or feature request):

In our community documentation we outline a strategy for how labels should be used across our repositories. Manually creating those labels is a tedious process that can quickly become prone to human error. Please create a tool that can manage labels in accordance with our guidelines.

What you expected to happen:

• Create a tool that accepts an owner/organization and a reference repository.
• The tool will scan both public and private repositories of the owner and apply labels and colors as they exist in the reference repository.
• The tool should output a report as it processes so that the user can see the results.
• The tool should have a test mode so that the changes can be viewed before executing.
• The tool should be made available to the public under our open source policies.
• Testing coverage should exist for the tool.
• Ensure that our community documentation for labels matches what exists in the community documentation so that the labels being applied by this tool are understood.

Related source links or issues:

• https://github.com/drud/ghlabel - this is an unfinished, but functional attempt at creating this tool.

What happened (or feature request):

We will be implementing a Contributor License Agreement across the organization that will apply to all repositories. This brings up the need for a general contributors document that outlines how we would like to engage with contributors.

What you expected to happen:

A document outlining our philosophy and procedures around contributing should be drafted.

Anything else do we need to know:

from @rfay
We're starting to collect some of these("team norms"), unstated but firmly held:

• Approving a PR almost always means having actually tested it live
• The PR creator generally pulls own PR after it's been approved and passed test, when the creator is sure it's the right time.
• Nontrivial PRs normally get two full reviews before pull. Smaller ones may be fine with just one.
• Significant PRs may need to be rebased near the end of their life so that the tests run with all current code (to minimize the potential of breaking master on pull)
• PRs are generally expected to include tests for the new features they're adding, or to prevent relapses on bugs they're fixing.
• The PR template includes a section for a manual testing procedure. Nearly every PR should have explicit instructions on how to do the manual testing.

What happened (or feature request):

We have outlined the beginnings of our issue workflow and provided several example queries to help visualize the work we are doing. The challenge with this approach is that it is complicated to follow and requires a large amount of manual process to participate in. The general idea for this issue is to outline a set of tools that can provide reporting and issue management. These tools should be useable by developers, project managers, traffic control, and project owners to improve the workflow experience. The tools should take into account varying pieces of information that can not easily be extracted from the Github UI. For example, the amount of time an issue has been in a particular state. They should also provide mechanisms to control our project boards as issues move through our workflows so that manual intervention is not necessary. Additionally they should be able to manage labels where appropriate.

Because this is a meta-issue this description will be modified until actionable issues can be spun off.

What you expected to happen:

TBD

What happened (or feature request):

We have changed the issue template format that we use since this repository was created. It would be helpful to update the templates that exist for drud/community to reflect the latest changes in the organizations

What you expected to happen:

• Update all issue templates.

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

Related source links or issues:

Feature Description:

Github is nice, but it does not allow the clarity of consumption enabled by readthedocs for documentation efforts. We would like to utilize readthedocs to generate a more approachable set of documentation around how we work and who we are.

User stories:

• As an documentation contributor I can evaluate my work on readthedocs
• As a documentation consumer I can find relevant information on readthedocs

Acceptance criteria:

• Readthedocs is integrated with this repository
• Readthedocs is properly displaying tagged version of master as stable that is publically available
• A dev environment exists tracking the dev branch of this repository that is not publically available
• A qa environment exists tracking the qa branch of this repository that is not publically available

Related links or issues:

• #29

Definition of Ready Checklist:

• User-facing feature: provides story or A/C in Gherkin format, or
• Architectural feature: provides technical A/C
• Dependencies identified
• Sized by team

R^{Product Owner} A^{Scrum Master} C^{Eng. Lead} I^Team

Definition of Done Checklist:

• Acceptance Criteria tested and passing
• Deployed on test environment
• QA performed & issues resolved
• Unit test and E2E coverage updated (if applicable)
• Builds without errors
• Internal documentation updated (if required)

R^{Eng. Lead, Team} A^{Scrum Master} CI^{Product Owner}

What happened (or feature request):

When DDEVians blog about DDEV, they are unsure about how to spell DDEV, when to use DDEV-Local, versus DDEV or ddev.

What you expected to happen:

A page within the community guide here that explains how to write about DDEV.

Would include:
Product names v company.
About referring to the products.
Where to get Logos.
Style guide we use as basis (Google Developer.)

Related source links or issues:

See ddev/ddev#681

Feature Description:

We would like to provide a more detailed explanation of the Primary Github Account field during the checkout process.

User stories:

• as a user I can get more information about github and upcoming providers during the checkout process

Acceptance criteria:

• The text under the Primary Github Account field should read "Connect your organization to your github account. Only alpha-numeric (a-z or 0-9) or "-" are permitted. Read more about Github and other providers."

Related links or issues:

Definition of Ready Checklist:

• User-facing feature: provides story or A/C in Gherkin format, or
• Architectural feature: provides technical A/C
• Dependencies identified
• Sized by team

R^{Product Owner} A^{Scrum Master} C^{Eng. Lead} I^Team

Definition of Done Checklist:

• Acceptance Criteria tested and passing
• Deployed on test environment
• QA performed & issues resolved
• Unit test and E2E coverage updated (if applicable)
• Builds without errors
• Internal documentation updated (if required)

R^{Eng. Lead, Team} A^{Scrum Master} CI^{Product Owner}

Feature Description:

We work with and interview assorted external vendors who often request access to our services in order to do their jobs. It would be nice to have a documented procedure for how to request permission to add users to a service that you control in your department, as well as a place to document who has access to what so that when we disengage from a vendor we can remove them from those services without having to hunt for where they had access.

User stories:

As a marketing manager, for instance, I would like to add a vendor to Google Analytics so they can conduct an audit that will inform whether we hire them or not. They may only need temporary access. I want to be sure that I, or other future team members, am not adding users inappropriately or to services that may somehow by compromised or corrupted.
I would expect to have a request process as well as a place to document what the vendor has access to. This also helps when another team member views something like the admin panel on GA and wonders who all the users are.

Acceptance criteria:

• A documentation page exists in the ddev handbook for granting access to ddev services (not sure of proper term here)
• There is a process for creating a request to add a new user to a service
• There is a process to record what users have access to for future decommissioning or other purposes

Related links or issues:

Definition of Ready Checklist:

• User-facing feature: provides story or A/C in Gherkin format, or
• Architectural feature: provides technical A/C
• Dependencies identified
• Sized by team

R^{Product Owner} A^{Scrum Master} C^{Eng. Lead} I^Team

Definition of Done Checklist:

• Acceptance Criteria tested and passing
• Deployed on test environment
• QA performed & issues resolved
• Unit test and E2E coverage updated (if applicable)
• Builds without errors
• Internal documentation updated (if required)

R^{Eng. Lead, Team} A^{Scrum Master} CI^{Product Owner}

https://github.com/drud/docker.php7/pull/3 introduced a nice template update for issues and pull requests. It would be nice to have a tool that would apply those across repositories in a similar fashion to how labels are being managed. This needs to wait until the label code is committed/reviewed.

Feature Description:

Discuss and then codify a process for integrating bugs into our sprint plans and cycles. Some ideas mentioned on retro/s:

• budget 1 day per sprint per engineer for bug-fixing
• budget the engineer who is on support for a week to also do bug-fixing that week
• budget 1 engineer for the entire sprint for bug-fixing
• budget an entire sprint and entire team periodically to do bug-fixing and tech debt

User stories:

Acceptance criteria:

• Incorporate a set-aside bug-fixing budget in our sprint cycles

Related links or issues:

Definition of Ready Checklist:

• User-facing feature: provides story or A/C in Gherkin format, or
• Architectural feature: provides technical A/C
• Dependencies identified
• Sized by team

R^{Product Owner} A^{Scrum Master} C^{Eng. Lead} I^Team

Definition of Done Checklist:

• Acceptance Criteria tested and passing
• Deployed on test environment
• QA performed & issues resolved
• Unit test and E2E coverage updated (if applicable)
• Builds without errors
• Internal documentation updated (if required)

R^{Eng. Lead, Team} A^{Scrum Master} CI^{Product Owner}

What happened (or feature request):

We've been working with legal to create a policy on how we license Docker containers and how they are affected by upstream licenses when our images are based on the work of others. That work resulted in a policy that should be made available to the public in our community docs.

What you expected to happen:

Convert the "Dockerfile License Preference and Selection" created as a result of https://github.com/drud/general/issues/128 into markdown and link it appropriately in the README's of the community repo.

What happened (or feature request):

We've been doing a one-off approach to style, and it shows throughout our code and docs. We'll be forced in the future to at least make a few decisions about style. Such things as how much to expose in an error message, whether title words are all capitalized or only the first, and a thousand things of the type. In many cases we can just adopt the approaches of others. For example, for our docs we can just find a simple stylesheet we can live with that has specifications for titles and such. For errors, we'll have to roll our own, but an agreed-upon strategy that balances the finish-level of the product against the user's need for quality information and against our ability to debug their problems is not that hard to come up with.

• Documentation stylesheet (or reference)
• User interaction (especially errors) stylesheet
• (and more?)

https://github.com/drud/community/blob/master/governance.md#enforcement indicates that we need an email address to receive communication. The receiving address should be [email protected].

Feature Description:

Add to developer process documentation that we want to always check-in vendor and keep it up to date.

User stories:

As an engineer at DDEV, I want to have process docs I can reference so I can stay consistent with company policies and best practices

Acceptance criteria:

Write up and PR to developer handbook policy instructions on checking in vendor directories when developing on the platform.

Related links or issues:

Definition of Ready Checklist:

• User-facing feature: provides story or A/C in Gherkin format, or
• Architectural feature: provides technical A/C
• Dependencies identified
• Sized by team

R^{Product Owner} A^{Scrum Master} C^{Eng. Lead} I^Team

Definition of Done Checklist:

• Acceptance Criteria tested and passing
• Deployed on test environment
• QA performed & issues resolved
• Unit test and E2E coverage updated (if applicable)
• Builds without errors
• Internal documentation updated (if required)

R^{Eng. Lead, Team} A^{Scrum Master} CI^{Product Owner}