Organize issues & discussions across sub projects for priorization

[baentsch]

Beyond the current milestone tags for liboqs there does not seem to be an overall strategy (maybe only documentation) as to which issues and discussions shall be tackled in which priority/order, particularly if they straddle sub projects (such as issues regarding security, algorithm support or automation/CI). Some issues don't get attention for months and years, even.

If OQS were aiming to become more reliable software this should probably be changed.

This issue therefore is to suggest a discussion as to whether this is desirable and if so, how to facilitate that. Probably related to the question whether OQS want to attain some "product properties". But even if that question were answered with "No", this discussion may still be valuable as even researchers may want to have a mechanism to give priority to (resolving) some issues over/earlier than others.

[dstebila]

Yes, we should probably be more organized. There are a variety of Github features available to us: milestones, projects, labels, possibly more. We've experimented with those three over the years. Labels on issues/PRs are not super helpful because we still have lots of issues. Milestones have worked for our releases. I gave up on project boards because I found no one ever engaged with the project boards other than me.

All of that to say: I'm not sure how to organize things better, but if you or someone else has an idea on how, please suggest it or go ahead and try applying it and we'll see how it works.

[baentsch]

I gave up on project boards because I found no one ever engaged with the project boards other than me.

Just speaking for myself: I never understood how to use them (or they just didn't work the way I thought they should :-)

please suggest it or go ahead and try applying it and we'll see how it works

In the absence of other proposals, I'll try to learn some more about project boards and create one or two for this purpose...

Further proposals welcome, of course.

[planetf1]

The new project boards (beta) are useful as you can add issues from mutliple repos/orgs. Avoid the old ones. You can add additional fields, and views which can arrange tables or columns by these fields, + groupings etc. So you could have fields for the status (default), type or work, priority, impact.. whatever & then slice/dice in different ways. Simply having an unsorted column can be useful too as you can drag/drop to put items in order

All that being said, the key thing is to get buy-in. I've had similar issues with projects in the past in that it's difficult to get everyone happy with them. At least they are 'native' to github, and don't impact regular direct repo issue tracking. Let me know if I can help at all - but experimenting is a good start @baentsch

[baentsch]

it's difficult to get everyone happy with them

It's impossible to get everybody happy. Anywhere.

Let me know if I can help at all

Sure: What I'd hope for is a mechanism/view capturing all issues in all OQS sub projects in one view. Then be able to apply tags to them such as "algorithms", "infrastructure", "platform support", "production features", "experimental features", "CI", "release process", "security process" (for starters) and some sort of priority (say 1 for needs to be solved immediately by a maintainer to 10 may be solved by someone maybe eventually). "Slicing and dicing" then along these tags, priorities and sub projects to align them with a release plan. And if someone feels like adding the Linux Foundation "readiness" tags (i.e., issue needs to be done to achieve level x) to all issues, great -- if there'd be some alignment between issues and LF terms becoming visible, maybe that'd make me change my opinion towards their utility for OQS. --> Would you be willing to give this a try if you already know (how to use) that GH tool and explain it hands-on at a team meeting to ease the "learning hurdle"?

[planetf1]

@baentsch I can try to create an example board (ideally in this org). Maybe with a subset initially.

Some attributes of an issue come from the github issue itself. Tags for example are particularly useful as they're immediately visible and fully native to the issue. Opinions vary on how useful they are. Often they seem to become quite ad-hoc.

Other attributes get applied by the project - custom fields. This really helps with slicing/dicing in multiple dimensions. One thing I like too for experimentation is that assignment is only seen via the project and it doesn't cause lots of notification noise, especially when experimenting. Having too many dimensions/views can get everyone confused though....

I'll take this on to bring back to a future TSC meeting (do we have one scheduled?) or liboqs call.

[baentsch]

I'll take this on

Thanks!

to bring back to a future [...] meeting

Any chance to give this a try outside of meeting(s)? My effective work time is getting more and more out of sync with OQS meeting schedules (writing this comment before 0600 UTC :)

[planetf1]

Sure -today (everyday?) rather chaotic. We could do a webex/teams/zoom & try a first pass together if that helps & see if we can put something together to subsequently propose to the broader team? Generally mornings are best (as much work is with the US). Can arrange via email ?