Migrate to label-based point system

[kwiens]

We'd love to use your difficulty points, but my team has aesthetic problems with [5] in issue titles. I tried using the [5] point system and people really rebelled — it’s visual clutter in a lot of our other systems.

We'd like to use an API to synchronize our point counts (stored in labels) with CodeTree.

It would also work if you'd support numeric labels as points, but we could work around that by posting the values to an API.

Thanks, and keep up the great work!

[derrickreimer]

Thanks @kwiens! I've been giving this some thought. I think it will ultimately be best to migrate toward label-based storage for sizes. No ETA just yet.

[kwiens]

I think that's a smart strategy — then we can use Github's API and built-in authentication. Thanks!

[ajwaxman]

+1.

Here's a related issue for using label groupings in general: https://github.com/codetree/feedback/issues/67

[derrickreimer]

@awaxman11 good connection there. Thinking that size labels would be scoped like you mentioned on #67. E.g. size: 2

[kwiens]

Yes, although using numeric sizes keeps the interface lightweight.

[ajwaxman]

Now that we've been using Codetree more regularly our developers are sharing similar thoughts to the origin comment. Conversation from this afternoon:

A: what do the [1] numbers at the end of issue names mean? B: it’s from codetree A: ah got it B: the teams that use codetree have a hack to denote points remaining A: it's kind of confusing since it breaks the email thread in gmail B: agreed

[derrickreimer]

Thanks @awaxman11. Planning to run a little survey across folks using points right now to see if I can get a broad consensus. It's coming down to either making it configurable (labels or in title) or migrating everyone over to label-based points.

[ajwaxman]

Sounds great, thanks for the update!

[nZac]

Any news on how the size feature is shaping up? We aren't big fans of having the title renamed either. It makes a mess of the issue history. I would like to see it label based.

[derrickreimer]

Thanks for resurfacing this @nZac. It's time to circle back to this now that some other major blockers are out of the way. Will touch base soon.

[nZac]

Hi @djreimer, just pinging this again.

I found myself wanting this today as I am stuck doing this work manually. Labels would be a huge plus.

[edit: spelling]

[akatov]

:+1:

I was going to report a different problem as a separate issue, but I think it's good to report it here too, since it would be solved (presumably, judging by other Codetree behaviour) by using labels for sizes.

In particular the problem is that the sync of sizes only happens one way - from Codetree to Github. If I change the number in the issue description on Github it doesn't update the size on Codetree.

[derrickreimer]

@akatov it should update the size on the Codetree side within 1 hour (sadly GitHub does not send webhooks yet when title is changed, so we have to pick up those changes through polling.

That being said, the first phase of migrating away from title-based points is almost ready to ship. First phase will be to decouple title and size, with a utility to scrub the points from existing titles.

During this phase, sizes will live only in the Codetree database. Then, we will work towards next phase of syncing titles with labels in some fashion.

[derrickreimer]

Alright folks, an email just went out to everyone about this. I'll copy it here:

Many of you have pointed out the drawbacks of this storage method:

• It breaks the email notification thread when the title changes
• It looks cluttered in other tools and the GitHub interface
• It's confusing unless you know why it's there

Starting today, size data will not longer be stored in issue titles.

Some of you have expressed a desire to sync size data with your labels. Some prefer a simple numeric label, while others would prefer a namespaced label (e.g. "size: 5").

One of the greatest challenges faced by a product architect is reaching consensus among users when there is more than one viable solution on the table. Unfortunately, there is no clear consensus at this point. So for the time being, this data will live only on the Codetree side.

If you would like us to scrub the old title data out of your issue titles, please reply to this and let me know!

[kwiens]

Thanks!

Some prefer a simple numeric label, while others would prefer a namespaced label (e.g. "size: 5").

I'd vote for either proposal rather than neither proposal! I personally prefer the former but I would love to have the latter over nothing at all.

[derrickreimer]

@kwiens noted! 👍

[akatov]

I'd prefer a namespaced label, e.g. "size: 5".

Furthermore, I'd love configurable numeric labels, i.e. labels for more than just size, e.g. "impact: 3". Then, I'd love to have configurable values (that live only in codetree) that are an arithmetic combination of these github label namespaced values, e.g. "relativeImpact" = 2 * "impact" / "size" which for the above values would give 1.2. Then I'd love to see more (configurable) numeric value columns in the issue list, and I'd love to be able to sort the issues by those values. Finally, for milestones, I'd love to be able to specify more than just sum of all the sizes of issues to be shown, but e.g. the average impact of all issues.

Seeing that non-namespaced labels would make all of the above permanently impossible, I really would prefer namespaced labels, as this would at least keep alive a glimmer of hope for my above wishes to be realized in some distant future...

[akatov]

@djreimer what about having size parsed from the description, just like the needs #X interdependencies, e.g. needs #100, size: 1.2 - this way you don't need to define a massive amount of size labels (for someone that uses a lot of different sizes)..

[derrickreimer]

this way you don't need to define a massive amount of size labels (for someone that uses a lot of different sizes)

Yes, this has been one of my concerns. If using labels, I'd prefer to limit to a small set of fibonacci numbers for sizes, but I've been hearing folks want lots of flexibility (fractional points, etc).

The main downside that I see to putting in the body/comments is that it's not readily visible on the GitHub side when looking at a list of issues.

[dallasgutauckis]

Just want to chime in and say that I feel disabling sizing sync altogether is a regression. At the very least would have been nice to have migrated to labels or made some other decision regarding synchronizing with GitHub as a source of truth. In our case, our team mostly does sprint planning and sizing within codetree but when working issues prefers to use the GH interface for commenting, labels, etc.

I completely understand the complexities around trying to make a solution that works for everyone, but feel that's a task that may never be finished, and my general opinion is that the best solution is ultimately high customizability.

Is it possible to—until the time another solution is implemented—enable sizing via titles behind a repo/project-level feature flag or something? I'm not fond of the idea of losing our existing sizing information due to something happening with the codetree<->github sync…

[derrickreimer]

Understood. This is definitely a temporary thing during the transition period. I am most in favor of the namespaced label approach at this point. Any major opposition the that approach, Dallas?

On Tuesday, April 19, 2016, Dallas Gutauckis notifications@github.com wrote:

Just want to chime in and say that I feel disabling sizing sync altogether is a regression. At the very least would have been nice to have migrated to labels or made some other decision regarding synchronizing with GitHub as a source of truth. In our case, our team mostly does sprint planning and sizing within codetree but when working issues prefers to use the GH interface for commenting, labels, etc.

I completely understand the complexities around trying to make a solution that works for everyone, but feel that's a task that may never be finished, and my general opinion is that the best solution is ultimately high customizability.

Is it possible to—until the time another solution is implemented—enable sizing via titles behind a repo/project-level feature flag or something? I'm not fond of the idea of losing our existing sizing information due to something happening with the codetree<->github sync…

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/codetree/feedback/issues/155#issuecomment-211979671

Derrick

[dallasgutauckis]

If you mean the size: <n>, then that is what we were using pre-Codetree and I think we're fine with it, assuming it supports either arbitrary size values altogether, or our minimum set (esp. 0.5, but also 1, 2, 3, 5, 8, 13, 20, 40, 100) which we've inherited from

Note that we don't use ? or ∞ as they're effectively indicators that we need more info.

[derrickreimer]

Sizes are now being synced with labels in the size: X format. We are planning to release a migration utility soon that will:

• Remove the [x] size from titles
• Add size labels to all issues with a designated size

[kwiens]

Awesome! Is there any way to force a entire issue sync? I changed our label names but Codetree isn't picking up the change until I make a change to each issue.

This is very exciting! Thanks a ton.

[derrickreimer]

Great to hear! I'm planning to release a utility for migrating everything in one swoop. I can do this for you manually in the mean time. I'll follow up via email shortly.

On Wednesday, April 27, 2016, Kyle Wiens notifications@github.com wrote:

Awesome! Is there any way to force a entire issue sync? I changed our label names but Codetree isn't picking up the change until I make a change to each issue.

This is very exciting! Thanks a ton.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/codetree/feedback/issues/155#issuecomment-215146775

Derrick

[kwiens]

You're a rockstar and we love you.