jakartaee / jakartaee/servlet

Review Labels, projects and issues.

Open
#278 6 comments 0 reactions 4 assignees Claimed by @markt-asf View on GitHub
Process
Dominant language
Java
Stars
325
Forks
112
PR merge metrics
No merged PRs in 30d

Description

**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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.