Idea: scrap FF/CR tickets

Discussions - Public
1

So we currently have FF tickets autocreated for each sprint, to block time for FF work.

Now that we have the sprints app, the app could instead auto-block time for FF, and we could do away with the tickets.

Rationale:

  • Once the sprint starts, the FF and CR tickets are useless. We don’t log time to them, we don’t need to comment on them (in fact, we shouldn’t comment on them; we have the forum, ops review logs, created tickets for FF tasks …), etc.
  • The tickets add a lot of noise to the sprint backlogs.
  • They are annoying: you need to move their status along throughout the sprint, not forget to mark them as deployed by the end of the sprint, they get in the way of other tickets visually.
  • Their only use (afaik) is to block time, and sprints app can do that now.
  • We’re gradually moving to sprints app for more automation and general planning niceness.
  • These tickets continue to block time by default, which adds to the issues planning time commitment for the next sprint.

Thoughts?

3 Likes
2

This is totally the purpose of the Sprints app, I agree. :+1:

Are we supposed to log time on the CR tickets?

3

@anon46505572, @toxinu, this is not the case for the community relations task. We have to log the 1h of time spent doing community relations work on that task. It uses the OC-Contributions account.

Imho, it would be best to continue with our current process and not add a lot of OpenCraft-specific logic to the sprints app.

4

Do we, or will we, be implementing a generic form of this functionality? Like, if we’re able to add arbitrary tasks that need time taken up based on specs in the settings/configuration models, that would probably be helpful.

2 Likes
5

Sprints does already support a limited form of creating rotating tickets using the JIRA_CELL_ROLES setting, which can be configured at deploy time. See the ansible PR linked to from MNG-2415, which is how I disabled the Community Relations tickets.

6

Oh true, I missed that. I also see that we’re removing the CR tickets anyway.

7

They have already been removed. If they still appear in one of your sprints, it is most likely because the sprint was created prior to that change.

I don’t think the problem is with implementing OpenCraft specific logic into the Sprints app.

The problem is with creating the OpenCraft specific logic in non-generic ways.

Previously, I suppose, members wanted to avoid “over-engineering” things because Sprints was specific for OpenCraft.

But now, since there’s a plan to sell Sprints as a service, implementing OpenCraft specific logic can be contributed similarly to how we contribute code changes to the Open edX platform, through generic forms of the requested functionality.

If we have trouble doing so, I believe Fixate would be able to contribute awesome perspectives on generic forms of the requested functionality.

Implementing generic forms of OpenCraft specific functionality is definitely planned, even if it hasn’t been discussed before.

We want to use tools such as Sprints and the Workflow Manager and sell them as services, so we, indirectly, have to follow such an approach.

1 Like