Prioritization in Project Management

[egekorkan]

An open point in project management is how prioritize items. This is mentioned in https://github.com/w3c/wot-thing-description/blob/main/proposals/project-management/project-management.md in step 8. We need further discussion on this so here is the issue for it. My personal opinion is below. I probably forget some items but at least from the ones I can think of, this order makes sense to me.

1. Critical issues that stop all other issues. Examples can be a bug in the tooling, some bug we have somehow missed that results in a failure of rendering the spec etc.
2. Publication related issues.
3. Issues that impact other issues and block them.

The issues above have almost the same importance to me.

4. Tooling Improvements (until there is no need for improvement)
5. Work on Refined Use Cases, e.g. concrete specification of data mapping.
6. Use Case Analysis issues. Issues that are submitted by the Use Case TF that need an analysis. Even though this has high importance, it can be a big amount of work to analyze it depending on the use case.
7. Editorial fixes, refactoring

After writing this, I have realized that this is more of a list of importance or criticality. For prioritization, the size of the work needed should be taken into account. Maybe we can do some decision matrix where we have the size of work in a column and importance in a row. The intersection results in a numbering scheme and the higher the number is, the more priority we give to it. Maybe this is too analytical but this is a thought I had.

[danielpeintner]

I agree with the statements above. Anyhow, prioritizing tasks is a general problem, see

• https://asana.com/resources/how-prioritize-tasks-work or
• https://www.teamwork.com/blog/how-to-prioritize-tasks/
• ... or many many more

In the end, I don't think we can come up with mathematical formula and might need to to decide on a task basis...