After today’s discussions about releasing from @tbrisker it seemed right to bring this back to everyone’s attention. I do still need to get the upgrade to Redmine sorted out, but that’s probably going to be started on next week. Then I can look at question/needinfo plugins - although we do that the “Feedback” status already, could that be used?
Assuming some/all of that can be resolved, do people still want to give a regular triage a go, at least for a trial period?
I’ve often wondered how/when Foreman triages issues and who’s invited, so thanks for bringing this up!
Katello already has weekly triage Wednesdays at 13:30 EST, which we generally announce/share in #theforeman-dev IRC channel. It’s a large plugin with dedicated engineers, so it makes sense to triage separately imo. I can see a case for triaging smaller plugins alongside core. On a side note, perhaps we should move Katello’s triage to discourse’s events?
Originally I wasn’t a big fan of triage, but the state of things recently has made me change my mind. In previous years, Dominic used to do at least some triage of new issues being reported and raised awareness of release blockers or other significant bugs. Since he left the project, no one has taken over the important task of going over all the issues being reported.
Even if we don’t assign all issues to specific releases, I think it would still be worthwhile to go over the new issues once a week, at least to identify the most critical ones and make sure someone looks into them in a timely fashion.
5:1 in favour so far, but this has gone very quiet. If the result hasn’t shifted much by Friday I’ll set up a date poll for when we should triage - if you’re not there you can’t complain if we assign bugs to you
@thomasmckay Indeed, this was already brought up in the prior discussion, and I think it’s a good starting point.
@lzap We can easily create new statuses, but we have a lot already. I think we’d be starting with “New” issues and either assigning them (so they disappear from the New list), sending them back to the user (Feedback status, iirc) or putting them in another group (e.g. I’d love to have a list of easy issues for new users to get started with). We have plenty of “New” issues, that should keep us busy for a few weeks while we see if we need extra statuses, filters, etc.
An issue without a release is considered untriaged. An issue with a release is considered triaged. There are two special releases:
Katello Backlog
Recycle Bin
Katello Backlog is for triaging issues that nobody is planning to work on in the near future and that are not relevant to a release. Recycle bin is where issues that go unresolved after 7-14 days go and then are eventually closed. This is also good for things like support tickets or rejected issues.
If a user or developer wants an issue to be re-considered in the next triage they can flip an issue from Backlog to no release. Issues in the backlog that get fixed and “closed” in Redmine flip to untriaged to bring to the attention of the triage meeting to assign to a release.
OK, this looks popular, we need to pick a time. Rather than a poll with a billion options, lets do this - I’ve made this post a wiki post, could those in favour list out some times that work for them?
This slipped from my radar, sorry. It seems like Tue AM works for everyone except @Marek_Hulan, or Thu PM works for everyone except @iNecas. Given Thu could also conflict with demos, I suggest Tue AM is the way to go.
Tomorrow is perhaps a little short notice. I shall schedule one for next Tue and we’ll see how we go
I’ve just realised I’m double booked for the first triage session (it’s a one-off thing, I will make it to others) so I’m nominating @tbrisker to run the first one
Does it make sense to add the Triaged custom boolean (see here: Redmine Plugin Spec) to the Foreman project? I think that would be useful, but we could also experiment with a text field if we want to assign issues to group backlogs?
Katello maintains a triage rotation as a wiki so other members may choose to sign up. For a while, we had the same person doing it each week, but it’s nice to have a break. I’m not saying Foreman should do this, but it seemed relevant.
Was thinking if we want to hide Priority field from the New Issue form if that’s technically possible. As of today, priority does not reflect our prioritization but rather what reporters think. We discussed introducing a second flag for users, but I think this will be confusing. Bugzilla already have Severity and Priority and both are opened for everyone and they are usually not set properly.
I think the reason for this is because we did a poor job moderating it. I still see value in allowing users for proposing something as high prio. And yes, there will always be users that will take ‘it’s my bug’ as the only criteria for marking something as urgent.
Maybe we will get there and really try to hide it, but for now, I would keep the option for the users to set it and let the new triage process settle down a bit first and see if this is really an issue later.
Agreed on not hiding priority. The Katello triage evaluates user priority and resets it based on the consensus of the group during the triage meeting. The priority can either go up or down in this case with a goal to assign a developer to high and urgent priority items to reflect that they actually are of that stature.
I had opened a PR to automatically set the release field when merging. Note that the current code has not been tested but it’s more about the processes now. Do we still want the PR processor to automatically set the release in some cases or does the current triage process already handle this?
The first couple of these have gone well, new timeslot is July 3, 2018 2:00 PM (Asia: Calcutta), July 3, 2018 4:30 AM (America: New York), July 3, 2018 10:30 AM (Europe: Prague) - more people are welcome.
However, we did want to schedule them in a NA-friendly timeslot from time to time. @cintrix84 et al., would the demo timeslot on a week with no demo work for you? E.g. July 19, 2018 6:30 PM (Asia: Calcutta), July 19, 2018 9:00 AM (America: New York), July 19, 2018 3:00 PM (Europe: Paris)
