Proposal for Software Improvement: Streamline Papercuts & Wishlist Process

Product Development Process
1

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
  1. 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

image
image2348×1326 486 KB

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

1600×899

Some concerns that came up during the work on this new process and how we propose to address them

  1. 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
  1. 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

@NickWeir

Support:

@Cecilia-Hn @lbwright22 @chez @RonellaG @Cobi

Delivery

@filipefurtado @lin_d_hop @Erioldoesdesign @Matt-Yorkley @apb @sauloperez @jibees

Feedback Deadline

Wednesday, June 2nd

3 Likes
2

Thanks @Jana for working on this!

It looks like a lot of thinking has gone into this. :+1:t2:
I currently don’t understand how the zoom fits into the other image. Where are the interfaces between the two pictures? Could you make that more clear please?

Also this box has two exits but no question to answer. How is decided which way to go?

Screenshot_20210521-101620_Chrome
Screenshot_20210521-101620_Chrome1079×979 69.8 KB

How will we see where in the process a wishlists item currently is? Will there be a ZenBoard reflecting this?

I also wonder if every single wishlist item/papercut has to go through the full process, taking up valuable time of the paid core team. Have you ever thought about a community/volunteer track where people incept small things (that do not affect the whole functionality of the product) on their own, code it and it only gets a quick review by the product circle before merging?

These are my thoughts. It’s a really complicated topic! So thanks for taking on this challenge again!

3

Thanks for your feedback @konrad
I´m only going to reply to the things that need clarification, not yet the “process discussion part”

Well spotted, the connection line was leftover from the old process chart. Deleted and updated.

I currently don’t understand how the zoom fits into the other image. Where are the interfaces between the two pictures? Could you make that more clear please?

This is a detailed view what happens in the 2nd step “Product team identifies feature candidates and papercuts”, and before 3rd step “Community votes…” as I understand it (@Rachel to confirm)

4

Yes, it’s a breackdown of this step.

2 Likes
5

Thanks @Jana

I am happy to use Github (easier to have everything in one place rather than discourse and github).
As long as any procedure is well mapped out and I am aware of the steps then happy to follow (and ask others in UK to follow). Also happy to be a ‘test guinea pig’ git hub issue reporter for the new system before it is rolled out to everyone (I know at present there are some difficulties with permissions and as a reporter I can’t assign things as potential paper cuts which means I feel guilty just adding them in with everything).

1 Like
6

This looks great to me – I just have one thought to add, for discussion: In the template for ‘create a software improvement issue’, in addition to flagging number of current users affected, it might also be worth including a category considering number of requests we get for a specific feature from current and/or potential users

just thinking of scenarios where we, for instance, run demos for hubs or CSA looking for particular features that we don’t currently offer – and the lack of this feature results in them looking for another provider and/or hiring a developer to build them their own sites – seems like these cases should also be tracked and factored into decision making process around new feature development? I imagine this kind of scenario will generally apply to whish items / new feature candidates, rather than papercuts??

2 Likes
7

I love this so much, and feels supportive of the instance managers and other local people who spend very little time in github but who want to be good citizens and also understand how to get their problems solved. THANK YOU!!

I think using github is a good idea, and clarifying the process will cause more people to participate more often (and get better at making a good problem statement - I imagine it might be rough for newbies). Two suggestions/comments:

  1. For clarity, in the zoom-in diagram, it would help to know who does each step and when/how often it happens, for instance:
  • how is “discuss with community” accomplished?
  • who decides if the need is well-specified, and when? And if it is not who sets up the call?
  • who decides if the issue is a potential papercut? when/how?
  • I am assuming that the product circle does all the things along the right side of the diagram?
  1. I wonder if there was some place where someone who is just moving through the process for the first or second time can identify a “buddy” or guide to help them walk through it. This could be someone in the product circle, or it could be someone in a local instance who has done it a few times and can provide realtime feedback (like everything from how exactly to open an issue to what level of detail to include in order to continue through the process). Some will not need this of course, but for others it will be a welcome confidence builder and allow for deeper engagement of the process. Ideally a local person would be able to say “I know how to get my ideas and problems heard, and I know how to follow my suggestion all along the path to the point where it is implemented or at least I know how to keep an eye on it”.

Definitely thumbs up to this process especially if it includes a way to support participation!!

1 Like
11

First of all, thanks to everyone for providing feedback to this proposal!

Quick update:

  1. Since no concerns were raised, we will proceed with moving the software improvement process entirely to Github
  2. As soon as the new repo is set up we will schedule a meeting (or 2, considering the time zones :)) to get everyone on board on the new process

Replying to some of the questions and suggestions made by the community

@konrad

I also wonder if every single wishlist item/papercut has to go through the full process, taking up valuable time of the paid core team

At least for the start we think that´s the best way to ensure the product team keeps track of everything concerning the software improvement. Also, be aware the wishlist just accumulated over time but it´s actually not that many requests coming in on a weekly or monthly base at the moment.

where people incept small things on their own, code it and it only gets a quick review by the product circle before merging?

This might lead to more admin overhead to review and change than managing the whole process.
This is how OFN operated earlier and from experience, lots of things got incepted but no developers were available to develop it (until the end). So things stay in inception too long and needs to be redone later.
This proposal is an attempt to manage the work better and reduce the lack of coherence.

@lbwright22

As long as any procedure is well mapped out and I am aware of the steps then happy to follow (and ask others in UK to follow).

We are going to update the handbook asap :slight_smile:

I feel guilty just adding them in with everything

You shouldn´t feel guilty :wink:
And with the new process you´ll be able to label an issue as Papercut and it’s quite quick for the team to review and close or move somewhere suitable.

@dthomas

it might also be worth including a category considering number of requests we get for a specific feature from current and/or potential users

That´s an interesting idea.
Our concern is that the metric will be hard to use on a global level:
if for example 2 users ask this in Canada → what does it mean for OFN global?
If you could track / measure on a global level, for example with the product map that we came up with for tracking support requests that could be interesting for the future. See this post

I imagine this kind of scenario will generally apply to whish items / new feature candidates, rather than papercuts??

Correct!

@lauriewayne1

who decides if the need is well-specified, and when? And if it is not who sets up the call?

Who? Product Team (or “Papercuts Comittee”)

When? We would start with bi-weekly review and then maybe move to ongoing, depending on the number of submissions

Who sets up call: Product Team (or “Papercuts Comittee”?)

who decides if the issue is a potential papercut? when/how?

Who & when? same as above

How? Following the list of the Papercuts criteria

I am assuming that the product circle does all the things along the right side of the diagram?

Yes.

where someone who is just moving through the process for the first or second time can identify a “buddy” or guide to help them walk through it

The idea was more to have an initial call to walk though people through the process for the first time
(See 2.) instead of having an on-going buddy.
If that´s not enough, we can do an additional session after a couple of weeks where people should collect ideally their ideas for papercuts before already and we can do it with a practical example