How should we track maintanance tasks and feature implementatons?

[gasparnagy]

My original idea was that we keep the "Issues" list for public facing issues, that we should fix & close as quickly as possible, but for everyting else (feature implementartions, maintanance tasks, etc) we use the projects.

Now as I started the play with the new project system I realized that it has some massive UX issues (see why is everything a draft?), so I'm not sure anymore. The suggested workaround is to make a separate repo, just for the tasks on the project board and convert every single "draft" card to an issue there.

I'm not sure... Is this really the way we want to go? Any thoughts / suggestions?

[ajeckmans]

I was wondering about this as well. Specifically to keep track on what needs to be done before a new release can be created. I think the work-around makes sense. Keeping the planning issues separate from real issues and questions.

Taking this a bit broader I think writing down some guidelines around merging into the main branch, steps to create a release, how to block a release, when to update dependencies would be welcome. Unless of course the current status quo of you doing all of the work is ok :)

[gasparnagy]

My original idea was that we don't use the issues (of the Reqnroll repo) for features, because it pollutes the issue list (an open "issue" for longer time distructs our focus on the real issues that we want to fix quickly), but only use discussion items for these until we start working on them and they will have a PR. It can happen however, that we know that we want them to be included in a milestone although the implementation has not started yet. (My example of task Simplify target platform of Reqnroll to use .NET Standard 2.0 only is exactly like that.)

Arranging these to a milestone is maybe not that critical, so we can stay with how it is now, or we can also try to experiment with creating a task-issue for them in the .github repo. The third option would be to make a pseudo PR for these (a PR with an empty commit).

[ajeckmans]

That or we abandon the milestone completely and add a custom field 'target release version' to keep track of it all.

[gasparnagy]

Oh, that's a good idea. Let's do that for now at least!

[clrudolphi]

To clarify on how to track bug fixes...
Presume someone identifies a problem and enters a discussion item about it. We then create an Issue to track it, and eventually a PR to fix it.
Should all three entries be shown on the project tracker?
Which of those would be assignable to a release milestone?
After the PR is approved and merged, when should any of these be marked as completed - at the time of PR merge or when the Release is published?

[gasparnagy]

@clrudolphi These are all good questions and I don't know yet the answer - we need to see how it works. But in general, if someone identifies an issue and we simply fix it, we don't need to assign it to milestones. I would do the milestone assignment only for long-running, long-pending issues (which we should generally avoid). For the smaller ones we have the changelog anyway that is a precise description of what we have done.