"Roll-up" custom formula type: normalized, or not?

[Jan-Hendrik Spieth]

The documentation describes that Roll-up custom formulas apply "normalization".

The normalized value x for a field is defined as 100 * (x - min) / (max - min). where min and max are the min and max values respectively across all the ideas. Hence, the max value will be interpreted as 100 and the min value will be interpreted as 0.

I've checked roll-up with several different inputs, and never saw normalization applied. For example for a rating field:

Is this a bug in the formula implementation, or in the documentation?

[Tanguy Crusson · Accepted solution]

Hi @Jan-Hendrik Spieth , it's a problem in the documentation - the roll up just adds the values. If you want normalization, you can use a  "weighted score" formula

[Jan-Hendrik Spieth]

Thanks for the info, got it! I think it makes more sense this way, indeed.

Btw: normalization would be a useful addition to "custom" custom formula expressions.

[Tanguy Crusson]

@Jan-Hendrik Spieth thanks. What you can do is create a formula field / "write your own". Then create another one (formula / "weighted score") that has the first one as an input. That will give you a normalized value. 

[Jan-Hendrik Spieth]

Thanks @Tanguy CrussonYes, using a weighted formula field is an effective workaorund.

I would still prefer to be able to use a normalize function in a custom formula. Some reasons come to mind.

First and foremost, I don't like adding fields that have no real meaning/semantics/purpose, in the "human" sense.

Right now, each and every fields is available in the idea sidebar (and filter/grouping dropdowns, etc pp!), and thus potentially confusing/annoying regular JPD users.

Like these two that I created merely for "investigating" rollups vs weighted formulas:

Polluted filter dropdown:

Without these kinds of prefixes ("exp", "wip", "debug", "calc"), I would already lost with all my fields ... ;-)

This is totally ok in a beta, if you ask me. (And for educational experiments, I could lateron create a separate JPD project). But for production use, I would really like to keep the number of fields that are available to my stakeholders as low as possible, and limited to only what they have to really work with.

If Atlassian allows us to "classify" fields, as in fields for productive/interactive use, hidden fields, or so, then ok. Maybe you have sth like "custom field schemes" on the roadmap already. (Now that I think about it, I hope you do! One would certainly want to share fields across JPD projects ...).

I hope that makes sense.

Long story short:
If JPD allows me to mark/hide fields that are merely used for intermediate calculations, and hide them from JPD users, the workaround is ok. Otherwise, not so much.