deck icon indicating copy to clipboard operation
deck copied to clipboard

Feature/counting cards

Open bkrith opened this issue 2 years ago • 2 comments

  • Resolves: #
  • Target version: master

Summary

Add value field on deck cards and display sum/avg of each list. Is the idea Counting cards and created for nextGov hackathon 2022.

TODO

  • [ ] ...

Checklist

  • [x] Code is properly formatted
  • [x] Sign-off message is added to all commits
  • [x] Tests (unit, integration, api and/or acceptance) are included
  • [x] Documentation (manuals or wiki) has been updated or is not required

bkrith avatar May 01 '22 12:05 bkrith

This pull request came out of the NextGov 2022 hackathon

Abstract: The ability to count cards has been very beneficial in the past, in deck we introduce a sum of custom fields that allow you to rate and score new leads deals and truly collaborate with your teams.

Presentation slides

Demo video

florisvangeel avatar May 02 '22 14:05 florisvangeel

Any news about the merge/review of this cool feature?

matbgn avatar Sep 07 '22 07:09 matbgn

@bkrith @matbgn Thanks for your contribution and I'm very sorry for taking so long to reply. In general this seems like a nice feature, however the implementation is quite specific to a use case and from the product perspective we would rather have aimed for a more generic way of adding additional card metadata (like in #3472).

@jancborchardt @nimishavijay I'd like to hear what you think about this. Should we introduce such a specific field and what do you think design wise?

In general the code looks pretty solid from a first look, but there would be a few things that needs to get addressed before this could be merged:

  • It should expose this to the API endpoints and also properly document the API changes
  • Having some tests would be very nice, for the backend in terms of integration tests and frontend wise some basic e2e tests that ensure that those features continue working in the future
  • From my POV the unit is something that should be rather a board-specific setting as for some projects you might measure currency values while for other you might track hours or story points

juliusknorr avatar Nov 08 '22 07:11 juliusknorr

Time prefix sounds particularly interesting for projects, as can be used both as reporting "how long did it take" and estimating "how long will this take". So if the unit can be free text (with a low char limit, maybe 4?) then it can be used for many purposes, including ones we haven't thought of - where limiting it to selection restricts use cases.

Ideally the unit setting would be per list but that might be asking a lot :)

putt1ck avatar Nov 08 '22 07:11 putt1ck

Time prefix sounds particularly interesting for projects, as can be used both as reporting "how long did it take" and estimating "how long will this take". So if the unit can be free text (with a low char limit, maybe 4?) then it can be used for many purposes, including ones we haven't thought of - where limiting it to selection restricts use cases.

That seems like a case where more generic custom fields would be more suitable already for tracking more than one value. Same as for the different units per list, there it could just be different value fields and I feel like having a very specific implementation may then lead to users not making use of it and rather requesting another specific feature set.

juliusknorr avatar Nov 08 '22 07:11 juliusknorr

I think the high value part is the running total for a list rather than the bit in the card itself

putt1ck avatar Nov 08 '22 08:11 putt1ck

Agreed with @juliushaertl, a generic "Add new property" field would be more flexible. We can allow people to set the label and possibly a type as well (text, numbers, time, date, etc. ) :) If it's numerical field then we can show the sum or average like in this example with currency.

nimishavijay avatar Nov 08 '22 09:11 nimishavijay

@bkrith Would you be OK to update your MR in this way?

matbgn avatar Jan 23 '23 09:01 matbgn

Thanks again for your pull request. Given the previous statement we would rather aim for a generic solution. As there has been no further feedback I'd close this for now, but feel free to reopen to address the mentioned changes or just comment if anything needs further clarification.

juliusknorr avatar Oct 18 '23 09:10 juliusknorr