[RFC] Aging status of card (or a way to make visual management of cards that are getting old)

[matbgn]

Hello folks,

First of all I'm really glad to see that you're working on the future V2 and wish you all the best. 💪

It's been a while now that I've been wishing for this feature, and today I decided to make a Request For Comments here to prepare the future development I'll be doing in this way.

Goal

As a Scrum Master and also as a PO (Product Owner) I would like to be able to quickly see which cards are getting old or very old in our Backlog, for example, to help us make decisions about the future treatment of these cards. Similar to what you can find on some GitHub repos where very old and untouched issues are closed to keep the board clean, I will develop a similar mechanism but only visual (think of frozen cards or something like that). Then the user will always have the ability to move, update, delete the affected cards.

Process

First of all, I will list some requirements I see on my own, and in a second time, based on that, I will make a wireframe before coding anything. The goal behind this is to make my PR merge as smoothly as possible.

@@ALL So please don't be shy in this first phase and give any constructive feedback to make this RFC as realistic as possible in a short time frame. The goal is to make it as simple as possible so that the merge can happen in a few months. So at the same time please make simple or realistic comments and KISS

Requirements

• Firstly, this option MUST be an opt-in solution -> so no default behaviour. I suggest using an env var, does the maintainer agree? Or do you have a better approach?
• This change SHOULD mainly affect CSS / rendering stuff
• The changes MUST NOT affect performance on large boards. @@dev Team, what is a valid big board for your own internal testing? How many cards? How many columns?
• The design SHOULD be sober enough to be presented to business clients to give them a sense of the project's vitality (Maybe pulling some investments in a Sprint Review).
• ...but at the same time it SHOULD be fresh enough to attract attention at first glance to where the bottlenecks are.
• There SHOULD be three stages of ageing (1. dusty, 2. full of cobwebs, 3. frozen).
• The time frames of each stage SHOULD be freely customisable by each instance owner.

Last words

Voilà, that's the main concept. If you see other main points that should be added, feel free to add your comments. I can't guarantee that I'll include them in my first development, but we'll see. Of course, this doesn't apply to maintainers, for whom I'm waiting for a green lamp, or maybe at least an orange one.

Next step

Based on my description I will create a mockup or at least a kind of wireframe. In the meantime, I'm looking forward to reading your feedback (of course first of all the maintainers one), which could possibly influence my design idea.

[nickbe]

Hi Mat,

the feature you're suggesting is basically already on our list of things to implement. Although our idea is somewhat more complex for us. One of the first questions is: How is the age or liveliness of a card determined. Age or the last time of change in itself is not enough for me because it doesn't say anything about the actual card itself.

A card can be more or less important, changes can be more or less important, I can spend more or less time on or inside a card and so on.....

Do you have any specific ideas about how to determine the "age" of "liveliness" of a card?

[matbgn]

Hi Nick,

Basically we manage importance by tags/labels on cards, so here we just need a basic age indication.

I don't think it's a good idea to implement a more complex calculation here, because it really depends on each team's processes/habits, and basically what you want to avoid in Scrum is a big backlog with some cards absolutely not touched.

But maybe you have already thought of a really simple way to implement the logic behind your idea?

Mainly what I want to avoid right now is a big obstacle for a working MVP that could be iterated more and more depending on the capabilities provided by the v2.