Review Labels, projects and issues.

[gregw]

Labels We need to review the labels that we have to available on this project as there are currently too many and contradictory. I would like to suggest the following type labels:

• Bug (bug in the code)
• Build (how to build the code)
• Process (to discuss how we should operate the project - like this one)
• Documentation (javadoc or specification document (ha!))
• Enhancement
• Integration (with other EE components, project etc.)
• Specification (Orthogonal label Issue against TCK, documentation, ambiguity, other EE etc.)
• Question

On top of that, I think we could have the following action labels:

• Action:Accepted (reviewed by spec leads)
• Action:Won't fix
• Action:Duplicate
• Action:Help Wanted

We could also have some priority labels... but I'm a bit +0 on these:

• Priority:Low
• Priority:High
• Priority:Urgent

Finally, do we need Component labels? (see examples in current labels). I think not as there will rarely be a nice taxonomy of an issue and then even more rarely will it be applied.

Projects There are a few organisation projects available for us to use (eg EE9 ), but I think should have some servlet only based ones as, which we should use for each target release:

• 5.0
• 5.1
• 5.1.1
• 6.0

But the question here is, do we want to have beta releases and release candidates? and of course what are our version plans (eg after a mechanical rename in 5.0 to jakarta.servlet is our next release going to be a 5.1 with some cleanups or a 6.0 with major new features? I guess no harm to define both projects now and if we never do a 5.1 then those issues can be moved to 6.0 when that decision is made).

Issues Once we have labels/projects, I think we need to do a pass through all the issues and categorise them. I think this could be done by individuals initially, but I also think eventually a conf call or two would be helpful.

[stuartwdouglas]

• Bug (bug in the code)
• Build (how to build the code)
• Process (to discuss how we should operate the project - like this one)
• Documentation (javadoc or specification document (ha!))
• Enhancement
• Integration (with other EE components, project etc.)

Does integration really need its own label? I don't think it will get used very often, and really falls under the category of Enhancement.

• Specification (Orthogonal label Issue against TCK, documentation, ambiguity, other EE etc.)

I'm not really sure what this one is for?

• Question

I am +0 on this one, as an issue tracker is not really the place to ask questions, but I know it will happen so having a label for it is probably ok.

I think we may also want an 'Affects TCK' label to indicate that an issue needs to be coordinated with some TCK work.

On top of that, I think we could have the following action labels:

• Action:Accepted (reviewed by spec leads)
• Action:Won't fix
• Action:Duplicate
• Action:Help Wanted

Sounds good.

We could also have some priority labels... but I'm a bit +0 on these:

• Priority:Low
• Priority:High
• Priority:Urgent

I am -1 on this, I would rather target issues at milestones that we are planning to fix them rather than have a relatively meaningless priority.

Finally, do we need Component labels? (see examples in current labels). I think not as there will rarely be a nice taxonomy of an issue and then even more rarely will it be applied.

I don't think we need them.

Projects There are a few organisation projects available for us to use (eg EE9 ), but I think should have some servlet only based ones as, which we should use for each target release:

• 5.0
• 5.1
• 5.1.1
• 6.0

Do we actually need the project board or are milestones enough?

But the question here is, do we want to have beta releases and release candidates? and of course what are our version plans (eg after a mechanical rename in 5.0 to jakarta.servlet is our next release going to be a 5.1 with some cleanups or a 6.0 with major new features? I guess no harm to define both projects now and if we never do a 5.1 then those issues can be moved to 6.0 when that decision is made).

I think it would be good to do a 5.1 first, but I don't have a strong opinion either way. I think we will likely want to do Beta and CR releases, if only to allow for TCK testing (so the TCK does not need a snapshot of the API to pass).

Issues Once we have labels/projects, I think we need to do a pass through all the issues and categorise them. I think this could be done by individuals initially, but I also think eventually a conf call or two would be helpful.

[bshannon]

The platform project hasn't decided the criteria for future Jakarta EE releases, but at this point you should not assume that you'll be able to make incompatible changes (e.g., a "Servlet 6.0" release) after Jakarta EE 9. We might find a way to allow that, but we haven't had that discussion yet, so the same assumption right now is "no".

[stuartwdouglas]

We are not planning on making incompatible changes. Personally I am very much opposed to the idea, so there would need to be a very very good reason for any such change.

[gregw]

Hmmm is removing deprecated methods "incompatible"? Ideally we could do that in 5.0, but if not then in a 5.1. If we can't do that during a name change then when?

So taking in Stuarts feedback I think we have:

• Bug (bug in the code)

• Build (how to build the code)

• Process (to discuss how we should operate the project - like this one)

• Documentation (javadoc or specification document (ha!))

• Enhancement

• Action:Accepted (reviewed by spec leads)

• Action:Won't fix

• Action:Duplicate

• Action:Help Wanted

And either project or milestones for 5.0 and 5.1 I do like the project boards as they are good for tracking PRs etc., but perhaps this project doesn't really need them.

[markt-asf]

I think I'd drop Documentation as well. Bug and Enhancement can apply to the code, the Javadoc and / or the spec doc. And I suspect in most cases it will be some combination of the three.

I'm also not a fan of the implication that spec leads are the only ones allowed / able to determine that a bug is valid.

[gregw]

I still like Documentation as there are many issues that are not about changing behaviour, rather just improving the description of it. Also as we no longer have a spec document, there are going to be lots of tasks to either recreate that or to improve the javadoc so that it is not necessary. So I'd like to keep that.

Also I think something like Action:Accepted is important. Already this project has suffered a bit from too many committees and not enough process, where PRs have been raised, review and merged without approval from the spec leads. It is the spec leads job to ensure that rough consensus is achieved before we commit anything to master and that can be hard in a loose anybody can commit model. The servlet-api has gone from a nailed down only-the-spec-leads-can-modify model to a much more open anyone-of-many-committers can modify model. It think we need some structure to impose good review , but I'm not keen on reverting to the only spec leads have write permission mode. Having a label that indicates some level of approval so that work on the issue/pr is thus likely to be merged is a minimal process step that I think could help. Would Action:Approved be better? Note also that perhaps spec-leads is too narrow and that I'd be happy if we had more than just @gregw and @stuartwdouglas as critical path steps in the process, but I just don't think that should be every committer. Perhaps this label is more important for PRs rather than issues?