Replies: 1 comment
-
|
Thanks for bringing up this discussion and outlining chunks of work that can be turned into a sprint. The sprint organization section sounds good to me. The ideas behind the process were also outlined in this discussion and in this one, we talked about the time-frame. I would like to add that while the structure you outlined is okay the sprint will most likely be a mixture of a few different things. For example, in the next sprint, we may decide we will:
That's because not everybody knows or is interested or can help with the In my opinion, an ideal sprint should involve everyone in completing a task (that they expressed interest in) or a chunk of work that by the end of the sprint makes us closer to a certain goal. Using the projects for organizing issues/notes is a good idea IMO. Here's an example of an ongoing sprint in BTCPay and you can also see how the projects feature is used for a roadmap. I wouldn't bother about the name. Sprint is quite a common term in software development, and it should be left that way. Let's not go into the |
Beta Was this translation helpful? Give feedback.
-
Here's a list of ideas for "bundles" of work we can work off of one by one (as releases or sprints if you will). Main thing is that we get a group of people to focus their time on something specific so it gets done.
Project collaboration
Create a playbook for how the community can offer design support for projects. Includes initial project briefs, how to run projects, etc.
Discussions happening
Contribute section
Create a dedicated section that explains how to contribute to the guide.
Pavlenex working on this
Use case section
Extract the use cases from the Private Key Management into a separate section. Expand those use cases so they include more best practices and can also be referenced by other content. This avoids repetition and creates more consistency. Should also make it easier to have reference designs as each page author doesn't have to start from scratch.
Principles section
Extract principles from other sections (Private Key Management and upcoming Onboarding and Payments) and create a dedicated section. This avoid repetition and creates more consistency.
Design process section (idea)
Created a new section that includes information about user research, design tools and workflows and other practical information and tips that help designers and projects to practice design well.
Also include info about how running design projects via the community.
Page ideas:
Wallet UI Kit (idea)
Mature the kit so it reflects best practices from the guide. Guide prototypes can also stem from the kit. Ideally creates a positive feedback loop.
Website revision
Tackle visual tweaks, glossary interaction issue, mobile home page styling, etc.
Other ongoing work
Carried by individual contributors.
Onboarding section
Worked on by Maggie and Conor.
Payments section
Worked on by Johns.
Sprint organization
A good fit would be to line up sprints with community calls and newsletters, which occur every 3 weeks. This would allow us to announce, discuss, and wrap up sprints easily. This might also help us in ensuring that sprints are not too big. If we think the work takes longer than 3 weeks, it might be good to split it up further and make it more manageable.
A sprint also doesn't mean that all other work stops. The way I see it is that a few people decide to tackle a specific group of tasks during that time period.
I'm also not 100% sold on the term sprint (sounds too intense) or release. Maybe "Revision" or just "Update"?
@ConorOkus also asked about sprint planning. Especially for the first sprints, talking through the tasks, estimating time, etc would be good to do on a call.
@danielnordh had the idea of using Github projects for sprints. So each sprint would get a dedicated project.
Anyhow, just some thoughts to get this moving. What do you think?
Beta Was this translation helpful? Give feedback.
All reactions