[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jms-dev] Messaging 3.0 roadmap and organization
|
Ok, everyone. I have started laying down some thoughts on our road map and how we might "do this thing" :)
- https://github.com/eclipse-ee4j/jms-api/issues/242
Most of those are in TODO state currently. My primary goal was to enable everyone to submit ideas now.
As this is our first time and we're trailblazing (aka. no one knows what the process is) I put quite a lot of time into how we could organize ourselves.
Likely what we do with Messaging 3.0 will influence us for years to come.
# Road Map issue
I've created a dedicated Github issue for the roadmap, plainly titled "Jakarta Messaging 3.0". In my head this is the replacement for filing a JSR. The goal is to give the outside world a permalink to see at the high-level what we're up to.
People can easily comment on it. We can link issues to it. When we put our spec up for Community Review or Final Release, we can include a link to this issue. There is a `roadmap` label which would be just for this one issue, not for all issues in the roadmap.
If other specification projects did the same (one roadmap issue per spec), someone could easily see a high-level view of all of Jakarta EE.next, which is going to be very important over the next year as people do presentations and articles.
Example: https://github.com/eclipse-ee4j/jms-api/issues/242
# Use Case issues
The Road Map issue intentionally does not link to any specific proposals. It's too early to say any particular proposal is "the one." Instead it links to problems we want to solve. Each of these is labeled with `use case` and the idea is that they are a clear description of the problem and motivation.
A `use case` intentionally does not detail a specific solution. The goal is to enable detailed and competing proposals, all of which are filed separately and linked to the `use case`. If we ended up with a dozen proposals for a use case, that'd be amazing.
We can keep the `use case` issue updated to reflect our current thinking. Over time we may decide to highlight a few of the best proposals. Eventually we'd need to pick one or eliminate the `use case` from the roadmap.
Example: https://github.com/eclipse-ee4j/jms-api/issues/243
# Proposal
This is where you throw all the details about your preferred way to solve a problem. Ideally, there are many proposed solutions. These can start out very rough, but obviously need to evolve to be implementable.
Example: https://github.com/eclipse-ee4j/jms-api/issues/241
I've attempted to put some detail behind these here, including an important note that links are not legally acceptable proposals:
- https://github.com/eclipse-ee4j/jms-api/wiki#external-links
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
