For storage purposes, you should be able to define a custom "int" field today and get most of the harder/riskier-to-do-locally stuff for free (persistence, editing, transactions).

In the general case, I think we want to let you surface arbitrary custom fields on the list/card views (see T418). This is mostly a design issue, in that it would be nice to find a way to make this look good for installs which choose to surface a whole pile of fields. We can add config to dump fields onto these views fairly easily, but without some nudging I worry the lists will look very messy very quickly. We may be able to let the user tweak this a bit by providing a couple of options for how items appear. Assuming we can come up with a reasonable behavior for this in general, it should be applicable to custom points fields too. There are a few small performance things to look at here too, but most of this is just building it, seeing how funky it looks with the defaults, and then figuring out how to deal with that in a broader set of reasonable cases. This is definitely coming to the upstream in some form, but hopefully a nice-looking one.

We don't currently have concrete plans around points, but I think this feature is common enough that some sort of first-class support is worth thinking about. The use cases I've seen are generally either "points" or "hours", but I think both behave identically in practice except for the label. One approach would just be to have a custom "points" field type, which behaves like the "int" type today, but sums on columns and maybe has smarter card/list display logic. I'd want to think this through a bit more before committing to it, though.

Another consideration is that custom fields are relatively hard to change quickly right now. We don't have any specific plans around this, but my assumption is that the "points" field gets changed more often than fields like "description", and making it easier to change either that field specifically or designated fields in general might be worth thinking about. So far we haven't seen much demand for this, although there has been some interest in letting custom fields appear in the "Action" dropdown. I'm hesitant about that approach to this problem, though.

This is an interesting use, but overall it's not immediately clear how to abstract this into something that's flexible to be used by most installs. I think we have plans to show some various per task meta data already in our "foot icons" (in mocks, but not yet coded). This could tell you per task things like number of dependecies, or number of comments. We'd have to look at abstracting that into something you could customize per board. That part I don't think is too terribly hard, but not a v1 feature. The harder design part would be having some sort of "Project (Board) dialog" view that could spit out random information on the individual board for you.

We'll keep this around to see what other feedback we get.

◀ Merged tasks: T5527.

I started implementing like half of this, but realized we need to update the counts when you move stuff between columns.

Sooo yeahhh...

It would also be be nice if one could map a field with S/M/L/XL into points for the purpose of the sum. Or at least if that was possible if you wrote your own custom field class.

In T4427#70957, @epriestley wrote:

I started implementing like half of this, but realized we need to update the counts when you move stuff between columns.

Sooo yeahhh...

Now the counts are being updated when moving tasks between columns, so I guess that part of the problem is solved.

Turns out that some Wikimedia teams use these sum points in their (Mingle) workboards, and for them it is quite of a blocker not to be able to see these sums in Phabricator boards. They see that the UI is already in place, only showing the number of tasks.

Do you think you are going to continue working on the implementation you started?

Related task in Wikimedia: https://phabricator.wikimedia.org/T803

I plan to let you choose a custom field to serve as "points" instead of counting each task as 1 point, but this isn't a priority.

Hey, just wondering if you guys were still planning on doing this. It would be nice to have a way to track the expected complexity of a task for planning purposes and being able to assign points would be great for that.

@rbalik, see T4778: When will my feature get built, or my bug get fixed?

Heh ok, sorry for bugging you.

Here's my current plan:

Global Points Field: I'm going to make this global: all tasks share the same "points" field, and the field is not a function of which projects the task is tagged with. For example, this means that tasks in project A can't have "Bug Points" while tasks in project B have "Story Points". If different types of projects or tasks can have different kinds of points, we lose the ability to sum subtask points, show points outside the context of a project, show which users closed the most points, etc., and stuff like querying and analysis in Facts get more complicated.

I don't see much of a use case for multiple point types or believe this to be common in other software.

WMF does have a few internal use cases filed for multiple point types (https://phabricator.wikimedia.org/T96954, https://phabricator.wikimedia.org/T120042) but these don't seem hugely important and I think there are reasonable workarounds.

You can still have custom fields which track "Experience Points", "Bug Points", "Quest Points", etc., they just won't be represented on primary charting or analytic interfaces.

Disabled by Default: Although tasks will get a points field, I plan to disable it by default and require some sort of configuration to activate it. I think this feature is nonessential and not critical to many use cases, and want to continue shipping Phabricator with a focused featureset.

Boards will continue to show raw card counts if no points field is configured, since the number of tasks in a column is useful on its own, especially with recent changes to make columns internally scroll.

Quantitative: Most of our interest in building a points field is quantitative (charting, analytics, point limits in columns, etc). If you want a "mostly qualitative" points field (like S/M/L/XL), tags (now visible on cards) or eventual work on T4863 are probably better ways forward. For example, we can't guess what "M + XL" is when labeling a point on a chart, and "S + S + S + S + S" is probably not bigger than "XL", even though "1+1+1+1+1" is bigger than "4". You can use something like 1=S, 2=M, 3=L, 4=XL by convention if you want, but if your labels are ultimately "mostly qualitative" and 1+1+1+1 is not actually the same as 4, it's obviously going to be more-or-less meaningless when we show you a chart or progress bar that draws an "XL" task as four times larger than a "S" task or includes a value derived by adding "S + M + M + XL".

Non-Negative Integers: Points may be unset, 0, or positive. You can not have negative points. Negative points seem nonphysical and I can't imagine any use cases for them, nor find any use cases by Googling.

My best idea for negative points is that engineers could assign PMs tasks with negative points to let them earn a larger allocation for a sprint, but I have a hard time imagining that "buy the team pizzas to earn 3 more points" would really catch on, and this can be accomplished equivalently by editing the column limit anyway.

You also can not have fractional points. If you need to assign something a value of "1.25" points, declare a 4-for-1 point split and then give it 5 points?

(0-point tasks also seem nonphysical to me, but I'm not going to fight that one, and are at least theoretically useful as "container" tasks which simply sum subtask points in some future world where we have tree subtasks, and some strategies where points represent allocation rather than effort can perhaps make some use of them. This seems like conflating different things to me and reducing total available data, but whatevs.)

Fibonacci Planning Poker: uh maybe some day

There are a lot of more specific goals we could be pursuing here but I don't intend to touch any of it in the first iteration. I believe we can layer it all on top later.

well maybe I'll allow fractional points

but don't use them they are silly ok

points/currency/time are the main things I think people would try to track in a point field

Yeah, fractional points are OK if you're literally labeling the field "Estimated Hours".

With "story points", points are (at least, according to PM blog wisdom) explicitly not supposed to directly measure hours: a task should have the same number of points no matter who estimates it, and a junior and senior engineer should be able to agree that it is worth "5 points", even if it would take them 50 and 3 hours to complete it, respectively. That is, "story points" is not a function of who the implementor is, even though "hours this will take" obviously is.

(This sort of seems like it's probably often kind of nonsense to me because "complexity" is also a function of the implementor in my mind, but I just write code.)

Oh, also in the mock, I had let people set the "noun" for whatever their points were. Which could then be surfaced wherever.

Yeah, I'm planning to let you label the field with whatever you want, I just haven't figured out where I'm going to stick that. Current leading contender is adding some special stuff to maniphest.custom-field-definitions, but I don't love that for various reasons. I may just do some new maniphest.points sort of thing and put some UI on it.

A use case: "I want to see how well we're sizing points, show me all 4 point tasks"

That seems reasonable, I filed T10339 to follow up.

I noticed today that the maniphest.points field doesn't appear in the Conduit output for e.g. maniphest.query. I can't find a task addressing this, but it would be very helpful (I have several scripts that used our auxiliary points field, but since migrating that to maniphest.points they don't work any more).

It's present in maniphest.search.

Broadly, *.search and *.edit endpoint are replacing older *.query and *.variousnameslikeupdate endpoints, see:

https://secure.phabricator.com/book/phabricator/article/conduit/
https://secure.phabricator.com/book/phabricator/article/conduit_search/
https://secure.phabricator.com/book/phabricator/article/conduit_edit/

Ah, thank you. I'll update to use that.

Let me know if you hit issues -- it should just be better in every way than maniphest.query was, but I might have missed some data or something like that.