Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Better labels for git issue priority #477

Closed
aubergine10 opened this issue Apr 21, 2017 · 23 comments

Comments

Projects
None yet
7 participants
@aubergine10
Copy link
Contributor

commented Apr 21, 2017

A somewhat unusual use for milestones, but if we create 'priority milestones' it would help separate out the issue priority from other categorisations.

Milestones could be:

  • Urgent
  • Soon
  • Whenever
  • Ponder

Anyone got any objections to me trialling this next week?

We could try both approaches in parallel for a while to see how it works out in practice before making final decision.

@amcewen

This comment has been minimized.

Copy link
Member

commented Apr 22, 2017

Go for it.

The current system with the labels starting with numbers was to let us (ab)use HuBoard to make it easier to move things around and reprioritise them when we did a triage session.

However, I don't think we've ever done a lot of reprioritising things, so losing that isn't likely to make much difference.

We also haven't done a lot of triage sessions (two? three maybe? In how many years?). I think that's the bigger problem, and lets all sorts of issues languish :-/

The "Ponder" category is a good one. I'd intended adding a "Waiting for a champion" label so we could close some of the older issues that seem good ideas but no-one wants to run with, but add that label so they could easily be found as a group to look through in the future.

I don't know if that would work to clear out some of the clutter that would get shifted into the Ponder milestone? They're not quite the same thing (I think) but thought I'd throw it in the mix. Feel free to implement whatever you think most sensible though :-)

(And, btw, am appreciating your closing old issues and general poking of things, @aubergine10 💯)

@aubergine10

This comment has been minimized.

Copy link
Contributor Author

commented Apr 22, 2017

I'm not sure that it's working well to have both "stuff needs doing" being mixed with "stuff that's fun to do". It makes it difficult to get a handle on mission critical stuff. I can't see the wood for the trees.

I'll take a look at HuBoard first before doing anything - can I login to the DoES instance of HuBoard? (my email is guy.fraser1@gmail.com if required).

As for labels, I think we're already drowned in them to the point where it's actually getting difficult to work with labels. That was one of my motives for using milestones to denote priority - label culling.

I like the idea of having some way to denote "needs a champion" - in particular it would be good way to highlight things on the website as well (as part of #weeknotes).

I'll be doing another wade through existing tickets either today or tomorrow to prod those that look stale and hope to have a load more closed by next #makernight.

@DoESsean

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2017

Given that I'm basically going through all of my alerts and saying 'Don't delete this!', I just wanted to take this opportunity to echo what @amcewen said - that you're taking the time to go through all these and try to sort the wheat from the chaff is very much appreciated, and something that we should be better at doing (maybe I should open an issue...)

A new tag for things that are long term rather than mission critical could be useful (although I think, given our current naming scheme, that 'Holding Out For A Hero' is better than 'Waiting For A Champion,' Adrian), especially if that means that they can be closed and recalled easily later on.

@SayBeano

This comment has been minimized.

Copy link
Member

commented Apr 25, 2017

I'm a massive fan of MoSCoW beause it has a clear term to apply for not doing something (i.e. closing the thing) and fewer terms for backlog items / wishful thinking.

  • Must
  • Should
  • Could
  • Won't

https://en.wikipedia.org/wiki/MoSCoW_method

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2017

I like this a lot. Thanks @SayBeano

@DoESsean

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2017

@huffeec

This comment has been minimized.

Copy link

commented Apr 25, 2017

Technically shouldn't it be Mushcowo, which is also hipster for beefburger..

@amcewen

This comment has been minimized.

Copy link
Member

commented Apr 25, 2017

"And that was how, back in 2017, DoES Liverpool switched from being a co-working and makerspace and founded the now-legendary chain of 3d-printed pizza and laser-grilled burger restaurants..."

@amcewen

This comment has been minimized.

Copy link
Member

commented Apr 25, 2017

I know @SayBeano's suggestion makes lots of sense, but I'm also digging @DoESsean's far better punning :-D

@aubergine10 Point taken on the overwhelming-ness of lots of labels, but I think we should use them liberally. They're especially useful as a lightweight categorisation system for issues that have been closed, which is useful because the closed issues are effectively the DoES Liverpool memory - slightly disorganised, but that's because we're optimising for the common case of them not needing to be looked at again, under the assumption that someone looking through them is doing so for a reason (they're trying to find the details of how we last fixed the 3d printer, for example) and so have an incentive to overcome that barrier. (The alternative being that there's a much higher workload done when the issue is initially raised and closed, and IME there's no incentive for the work to be done then - plus a load of it is wasted, because lots of the issues won't be looked at again)

I think we can do a much better job of trying to explain how things work to newcomers. Hopefully that'd make things a bit more understandable? The intro is pretty basic at the minute, but that was mostly because I wanted to see if this system took off before spending lots of time on it. I think we can probably say that it has taken off now...

@JimSparrow

This comment has been minimized.

Copy link

commented Apr 26, 2017

So, what should we do.

I love the idea of simple prioritising and sorting. Do we have a consensus?

@aubergine10

This comment has been minimized.

Copy link
Contributor Author

commented Apr 27, 2017

Well, we can parallel run (let's try the MSCW tagging first) - I'll do the updates on Friday both in github and HuBoard and then we have next week to stroke our beards and ponder whether it's a step in the right direction.

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Apr 27, 2017

If we're looking at MoSCoW what about Organisers' actions being S.M.A.R.T. too? (or perhaps they already are?)

  • Specific – target a specific area for improvement.
  • Measurable – quantify or at least suggest an indicator of progress.
  • Achievable – state what results can realistically be achieved, given available resources.
  • Responsible – specify who will do it.
  • Time-related – specify when the result(s) can be achieved.

https://en.wikipedia.org/wiki/SMART_criteria

@aubergine10

This comment has been minimized.

Copy link
Contributor Author

commented Apr 29, 2017

I'll be starting on this task this week, but first wanted to ask if anyone is already familiar with any of the following - if so, are changes here on github likely to bugger up these things?

  • #Weeknotes on the website, google group email, etc -- public facing, widely used
  • DoES Equipment Status webapp -- public facing, but probably rarely used?
  • HuBoard -- mostly internal use, and not used much from what I hear
  • Any other integrations that might be affected? -- let me know!
@JimSparrow

This comment has been minimized.

Copy link

commented May 2, 2017

While this is going on, I wanted to draw attention again to the current priority labels.

1 - You're all I need to get by
2 - The time is now.
3 - Wouldn't it be nice.

I'm mentioning this as there are a lot of long term 'wouldn't it be nice' actions that do still need addressing, now marked as stale today and due to be deleted, that still are long terms aims or needs for us. I've done a few. If anyone has time to go through and save the ongoing issues I'd be grateful please.

Thanks
Steve

Thanks
Steve

@aubergine10

This comment has been minimized.

Copy link
Contributor Author

commented May 2, 2017

Those issues were so far beyond "stale" they're a biohazard - and some have probably started to evolve in to new forms of intelligent life.

Seriously though, if an issue hasn't been updated for over 2 years then the chances are that it either a) isn't necessary or b) won't ever get done. If there are plans to do something with those issues, they should be given the S.M.A.R.T. treatment so they don't linger on for another 2 years.

@amcewen

This comment has been minimized.

Copy link
Member

commented May 3, 2017

I like the addition of the "Stale?" label to help organise/triage some of the older issues.

When closing things I think it's also useful to note why they were closed, again with labels where appropriate. There's already a "wontfix" label for things we decide are problems but ones we don't (currently) believe are worth bothering with. I've created (from @DoESsean's suggestion) "Holding out for a hero" for issues that (a) are problems, (b) would be nice to fix, but (c) no-one has run at for a while.

My thinking behind that is stop us losing information about bits of kit. For example, if/when someone wants to get the Proxxon CNC mill running well, it'll help them to find what we know is wrong with it (rather than having to look through all the things that have been wrong with it.

We do also need to better document what the labels are (especially when they've got slightly cryptic song-pun names :-D), so I've spun that out as its own issue - #487.

@JimSparrow

This comment has been minimized.

Copy link

commented May 3, 2017

Thanks Guy. I'm all for removing older issues once it's established that they aren't relevant any longer. It's a great thing to look at the issues, establish what's needed and look at a different treatment for them as you suggest, deleting those which aren't. It's a good suggestion. Why don't we find a way to support you to do that?

Mostly, I'd like to do that before the 90 odd emails you've generated becomes 180 and then doubles again :) as at the moment each one, though very useful requires someone else to follow-on, check and do that themselves, which can easily be more time than is available - why I was urging a little more caution.

I had a chat to Adrian, who's at Maker night this evening (Edit - tomorrow night) if you are - and has some ideas. :)

Cheers
Steve

@aubergine10

This comment has been minimized.

Copy link
Contributor Author

commented May 3, 2017

Yup, I'll be at maker night :)

I've no idea how to reduce the amount of emails when doing bulk updates; so far my approach has been to limit to roughly 25 stale tickets per batch (the number will dwindle as time goes on).

@JimSparrow

This comment has been minimized.

Copy link

commented May 3, 2017

Thanks. It's not the emails so much, but what has to be done with them. Adrian has some ideas/plans around a triage though.

@aubergine10

This comment has been minimized.

Copy link
Contributor Author

commented May 3, 2017

One thing that would definitely help is if a label could be automatically added to all new issues, specifically the "Priority 0: Triage" label.

@aubergine10

This comment has been minimized.

Copy link
Contributor Author

commented May 3, 2017

Current state of prioritisation labels:

region capture 1

As we've got so many labels, I've grouped each category - for example, all rooms are prefixed "Room:", all tools "Tool:" and so on. With the exception of priority labels which have unique colour per label, all the other labels have been colour coded based on prefix (all tools green, all rooms blue, etc).

There are still some stragglers that I'm pondering over, but things are starting to look a bit more organised.

aubergine10 added a commit to DoESLiverpool/status that referenced this issue May 3, 2017

Fixed issue links in config.json
Labels were updated in
DoESLiverpool/somebody-should#477 causing the
links to break.
@aubergine10

This comment has been minimized.

Copy link
Contributor Author

commented May 3, 2017

Done - see #487 for next steps.

@aubergine10 aubergine10 closed this May 3, 2017

@aubergine10 aubergine10 changed the title Suggestion: Use milestones instead of labels for git issue priority Suggestion: Better labels for git issue priority May 3, 2017

@JimSparrow JimSparrow reopened this May 7, 2017

@JimSparrow JimSparrow closed this May 7, 2017

@aubergine10

This comment has been minimized.

Copy link
Contributor Author

commented May 7, 2017

?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.