Type of Feedback
Proposal / Discussion
Feedback round
Proposal / 1st iteration
Description
Flaws of the current process:
1.Tools confusion
- It´s unclear to the community where to open new feature requests: the guideline “everything should be in discourse first” is misleading as Papercuts shall be opened straight to GH
- Having 2 places (Discourse + GH) where both feature & wishlist candidates are submitted makes the process messy and increases “maintenance effort” for the product team
- Opening issues straight to the main repo in GH has two downsides
-
It makes the main repo crowded.
-
many new contributors are trying out to solve potential papercuts but not all papercuts are ready to be picked up
-
some instances do not have the “product capability” to correctly contribute to the papercut process
3.The current wishlist template is cumbersome
That´s why the product team proposes to move both the wishlist candidates as well as potential papercuts to a central new repository in GH, using a single tool to streamline the software improvement in future
This screenshot gives an overview of the changes to the overall process
And this zooms in the new process (with the wishlist prioritization/new voting process to be defined in the next step), how an software improvement issue is “processed” after submission to the new repository
Some concerns that came up during the work on this new process and how we propose to address them
- How is the community going to use GitHub? Will it create more problems and support needs for instances without enough product capacity?
Proposed improvement:
- To kick-off the new process have an initial call (with instance managers + support people, one for american timezone, one for european + australia) on how to create issues on Github with the new wishlist template
- Set up calls with an instance when extra support by soomeone from @product is needed to get specific candidates into the pipe
- Will the community still exchange on wishlist items as much as they do now? How to ensure community involvement for topics that need wider discussion?
Proposed improvement:
- Product team (or the team that is reviewing submitted issues) checks if a topic should be open for wider debate / workarounds which will then be transferred to discourse. That should happen only for feature candidates
- For this we could come up with criteria, like check if a problem is common for more than 1 instance
Thoughts and ideas for improvement very welcome.
Next Steps would be:
- Create a new Papercuts + Feature request repo in GitHub
- Move all remaining items from Discourse to GitHub and close outdated ones
Who to ping?
Instance managers:
@dthomas @Rachel @lauriewayne1 @berniemabbs @konrad @thomaz @romale @Kirsten @VPotvin @hernansedano @alvarosaco @satya @DavieP @DavidGiovannini
@rafat-khashan @Eugeni @kristinalim @Bevan @Bato
Support:
@Cecilia-Hn @lbwright22 @chez @RonellaG @Cobi
Delivery
@filipefurtado @lin_d_hop @Erioldoesdesign @Matt-Yorkley @apb @sauloperez @jibees
Feedback Deadline
Wednesday, June 2nd