fastruby/points

Add a `state` attribute to stories

arielj opened this issue · 11 comments

https://ombulabs.atlassian.net/browse/DT-253

Branch/Commit:

Main branch

Describe the feature:

We can have different states for stories: pending / approved / rejected.

A story will be created as pending and another person working on that project should approve / reject the story. Kinda like a PR review for example but really simplified.

Only approved stories would show up in the action plan, rejected/pending stories won't.

Problem:

Currently, when it's decided that a stories won't apply to a project, the only option to remove it from the action plan is to delete it. It's a problem because it hides information to other people working on that project, they may not know if that was discussed or not and may add the story again.

Also, it will induce other people workin on the project to review the stories and approve them so they show up in the action plan..

I will abide by the code of conduct

I don't understand this feature, if a story is added to points it means it should be part of the upgrade so it's "approved" why it will be crated as pending? The approval thing is done before adding to points

fbuys commented

It often happens that a person adds stories to points and the team decides that the story should not be part of the estimation. Later on we might wonder why we did not add a story and we can then reference the stories that we decided should not be part of the review.

TLDR; For reference

I was not getting it, Thanks @fbuys that totally makes sense

fbuys commented

An outline of what is required:

  • A migration adding the new state field (the field could be a boolean called approved too)
  • A controller action for updating state
  • Perhaps JS to update the state using AJAX
  • Story index design changes to reflect new states pending / approved / rejected
  • Perhaps the ability to hide and show (or filter) stories based on their state
  • Ability to edit state when you edit a story
  • Ability to edit state from the story index page (perhaps a action added to the vertical dots menu)
  • Scoping to remove pending/rejected stories from the action plan
  • Tests

Is there something I might be missing?

fbuys commented

After some discussion with Natalie the UX change required are.

  1. Add a filter above the table, so we can hide/show based on status

  2. Add a new column next to the Story Title column called Status

  3. The new column will contain a label/tag representing the status
    a. Yellow tag for pending status
    b. Red tag for rejected status
    c. Green tag for accepted status

  4. Changing the status might need that we add another action to the vertical dots menu

  5. We can add the status to the story show screen as well, so it can also be changed when you edit/view the story description.

fbuys commented

A rough sketch:
image

fbuys commented

Another alternative is to add two buttons to the status column.
Pending: both buttons are shown as ouline buttons
Rejected: reject button shows red/filled in, accept button is outlined
Accepted: accept button is green/filled in, reject button is outlined.

@fbuys I think it would be more useful to have an option to change the status in the individual story show page, because we're most likely already in that screen reading the description to understand if it should be approved/rejected, I don't think that will be triggered from the list of stories in a normal flow and shouldn't be part of editing a story either

Like here in github, you don't approve/reject PRs from the list of PRs, you have to do it from the PR itself

About filtering, it's kinda easy but I don't know if it's needed, I would push them at the bottom though so they are not mixed with the rest

One more thing to add to the requirements, when cloning a project, the stories should all be cloned as pending

1.) "A story will be created as pending and another person working on that project should approve / reject the story" -- should we restrict someone from approving a story they added themselves?
2.) Do we need to keep track of who approved or rejected the story?

I'll be working on this