I wonder if this could be just a patch that assumes Story Points = 1 as sane default instead of zero.

Uhm. It seems that Phorge/Phabricator does - as default - this thing that 1 point = 1 card.

For a proof of that, just visit this page in this very same website I'm writing where "custom Story Points" are not enabled:

https://we.phorge.it/tag/phorge_upstream/ - see that there are 7 points and 7 cards.

Note that this "custom story points" thing is probably enabled only in Wikimedia Phabricator, not in Phabricator/Phorge itself.

I don't know how to rephrase the title of this Task with this info.

@MBinder_WMF Does it still describes your goals, or have I distorted it too much?

By the way I have not understood if you are aware of this situation (I was not):

https://secure.phabricator.com/T10915#188323

It's been suggested that simply defaulting all tasks to 1 point solves this issue. However, that raises other issues (for instance, some teams may already be using the Story Points field for actual story-pointing).

I saw this sentence and I didn't understand it. I don't see how varying the default "assumed value" could create problems. If you have a suspicion please clarify that it would help me a lot to understand. I definitely have a limited view on the impact of this. I think someone might complain if they set the Tasks Points as 0.1 or 0.5 or other fractions and then «oh no, the default is worth more». But honestly it seems to me that more people are complaining about defaulting to zero, than people are complaining about a future natural defaulting to 1 (which the user can still change per-Task, by the way).

Hi! Thanks for following up on this. :)

As I mentioned in my original description, defaulting to "1" solves one problem and creates another. I don't think it is a legitimate solution. "1" means something already, and as you suggested fractional pointing is also a thing. Bugs also do not get points.

Uhm. It seems that Phorge/Phabricator does - as default - this thing that 1 point = 1 card.

I'm not sure this is true. I think it's just the card count, and the Story Points are not active.

By the way I have not understood if you are aware of this situation (I was not):

https://secure.phabricator.com/T10915#188323

I have seen this, thanks for raising it again. In my opinion and experience, users don't understand this, so while the data "should already be pretty reasonably available" in the UI, it is not in the UX. This strikes me as a "see documentation" approach to "won't fix" rather than bringing the software up to standards. It's asking too much of the user, especially if they expect something else.

So, if I have understood correctly,

You say: it would be nice to have: 1 - not just this:

But - in addition to Point Limit - also another field like Count Limit - and somehow highlight not just when you go over the first limit, but also when you go over the second. Is it right?

(Note that I'm just a Phorge user and not a maintainer or site admin - I'm just trying to help for no good reason in the world. I know Phorge can be frustrating but let's improve this nice piece of software ihih)

Thanks for your help! Much appreciated that the attention on this is being raised. :)

Really, there is no such thing as "point limit" in standard practice, at least for columns (there are limits for entire sprints, but that's another thing). The fix should really be changing WIP to use count, not points. I just didn't want to advocate for removing something that someone might be using by now, so I've focused on what my users want.

However, if it is easier to shift rather than add the feature, that is preferable!

I don't think the hundreds of installations that use Phorge would want to abandon the way they do their thing so drastically. That is why I suggest to think about something that helps both them and you.

For example, if you ignore the columns for a moment and don't use them, what you say then would make sense for the Milestones as-is. So, you create a Milestone (note: a Milestone can have columns), and you set Point Limit to that Milestone. Then, you say: I would like, on the Milestone's columns, to have a limit per count of Task and not another limit by Point. This is probably reasonable enough.

Tell me if we can formalize it better not to be too drastic.

Knowing Phabricator community a little, I don't think this feature was implemented so lightly and so wrong as you mention. I want to say, I think therefore people will be not willing to accept "their" workflows as wrong and "your" as correct, and we should avoid a breaking change. We probably can.

I like your assumption of good faith! I'm a little more cynical about the thoughtfulness of Phab development, and the thoroughness of features deployed. I'll try to follow your example. :)

In any case, I don't think we need to advocate to remove story point WIP (I was just explaining my ideal). I think we need to advocate to add and option for task count WIP, and to stop using the existence of story point WIP as an excuse to not, especially considering Kanban, where WIP tends to originate, traditionally does not use story points.

I honestly think that adding a new feature called "Count Limit" on Columns would be useful for you, so that you can use Points Limit on Milestones; and Count Limit on Columns (and ignore Point Limit on Columns).

Feel free to mention a reading or training to further deepen this specific workflow, so maybe other volunteers/folks can better understand this point of view.

Having said that, in the meanwhile, as workaround, probably you could just - in few clicks - add "1" as Point in each Task. Then, use the Point Limit just as a "Count Limit" logically. If you would go for this approach, it would be great for you, because then you could ask the Wikimedia Foundation to, simply, assume 1 Task = 1 point by default, and I think that would not be a problem for anyone there. I say this since I want to suggest something quickly feasible for you, without waiting to reach consensus for a breaking change on everyone else in the Phorge world (which in any case maybe deserves a discussion).

Thanks for the suggestion. Default-to-1 has been mentioned before, and it's not feasible because of teams that need to cross-tag, where some teams use Story Points and some don't (thus, 1 point means something to one team but another thing to another). It's also common for 2 teams to use story points but have different meanings, where 1 point is a totally different scale depending on context.

I agree, adding count limit to columns and retaining point limit for milestones is an ideal compromise. :)

It's not that anyone is complaining about WIP'ing story points (it's just odd because it's not really a thing), it's that WIP, in Agile development, is designed for Kanban and task count, and it can't be used in its current iteration (so nobody in our org does, despite the feature trying to exist).

I've shared two proposals, that are actually requests for comments. I would be glad if some people could give a look and share a comment.

@MBinder_WMF: Also, under the hood you're saying that, since Wikimedia have multiple teams (multiple Tags) it would be nice to allow to change Task Points without interfering each other,

So, it would be be nice to save Points also on the tuple <Task, Tag>, so each team can override Task Points without interfering with others' logic.

→ This thing is safe to be discussed separately from this Task since it has no influence on the two approaches exposed here.

@MBinder_WMF - how much of this will be solved if we just add a tooltip to the [ X | Y / Z ] header?

In T15100#5480, @avivey wrote:

@MBinder_WMF - how much of this will be solved if we just add a tooltip to the [ X | Y / Z ] header?

By "tooltip" do you mean something that activates when hovering with a mouse?

By "tooltip" do you mean something that activates when hovering with a mouse?

Yes - some text describing what the code means.

I think a tooltip would clear up some of the confusion around the numbers and what they mean. However, I think the issue described here is less about how confusing it is, and more about how the UX expectation is typically centered around count rather than points. For example, which has the denominator, turns the UI red, etc. So, a good idea! I just think it's separate. :)

OK.

I don't personally have much insight into the "board" functionality, because I've never used boards in any setup other then as a simple table, and none of the workflows that involve moving small pieces of paper around make sense to me.

But this task, along with T15131, T15210, and all most of https://secure.phabricator.com/project/view/773/ do suggest some technical changes into making more-abstract "columns of things" setup, with the goal of allowing (probably using extension code) to define custom "board" setups.