-
Notifications
You must be signed in to change notification settings - Fork 33
Home
Welcome to the Jakarta Messaging Specification Project! This is the proper place to come and express ideas or use cases for messaging standards for Java.
Note
|
All ideas that lead to improvement of the specification are welcome, including use cases and detailed accounting of how the API might be difficult or hard. Everything submitted will be discussed for weeks, months or years. If you have an urgent Messaging issue, this is not the right place. |
Often times when we imagine a problem we can think of several ways to solve it. We tend to pick one and present that to the world, starting the discussion with the solution; "we need x."
Congratulations, you’ve executed a mini-specification exercise alone, start to finish. The same process must happen with everyone included, start to finish. For this reason, we ask:
-
Submit your problem as a github issue labeled
use case
. Be detailed on what issue you think needs a solution. -
Submit your solution
-
as a github issue labeled
proposal
. You may submit zero or many proposals. -
or as one or more pull requests to the https://github.com/jakartaee/messaging-proposals repository. See instructions in The Proposals repository page
-
Here is the workflow that split enables:
-
Step 1: As a community we will flush out the
use case
, make sure everyone understands it and discuss the value of the problem. If we don’t agree on the problem, we can’t agree on a solution and we are stuck. -
Step 2: Several ideas on how to potentially solve it will hopefully emerge. Each should become a
proposal
that is filed separately and linked to theuse case
issue. Consider submitting all the potential solutions, even the bad ones. -
Step 3: Proposals that are well-defined enough to be prototyped, hopefully are prototyped. Lessons are learned. We potentially see something complicated in the problem we initially missed.
-
Step 4: We decide if any of the solutions to the problem are worth the cost.
-
Step 5: We have solution we like, so we can move forward and develop specification text and TCK. Hopefully there is a prototype.
-
Step 6: We want to release our awesomeness to the world! An implementation is now mandatory.
Anyone can submit a use case
issue and there is no requirement you have any proposed solution. You are 100% encouraged and will be applauded for submitting a juicy use-case for others in the community to chew on. Problems looking for a solution are significantly better than solutions looking for a problem.
Your submission should have:
-
A code snippet or description to illustrate
-
A clear and short bulleted list of the pain points
Perfection not required, just do your best.
If you have ideas on how to solve your use case
, filing the solution separately:
-
enables others to submit potential solutions along side yours.
-
enables you to submit solutions other people’s problems without having to restate 100% of the problem description
-
enables you to easily submit all the good and bad ideas you had — maybe someone sees a way to make the "bad" idea work and then it becomes the idea you both love
-
avoids situations where people are proposing solutions to two slightly different problems (and therefore get nowhere)
The last bullet seems funny, but is more common than you might think. Frequently a proposal reminds someone of a related problem they had once. They enter the discussion with good intentions. If you started the discussion with a proposal
and thinly defined use case
, then all the time wasted is on your shoulders.
Proposals can start out rough. Be aware:
-
they eventually need to become detailed enough to implement
-
someone may even try implementing it and as you questions
Links to your blog are not suitable proposals. For Intellectual Property and Patent reasons, you must copy/paste the entire contents into the issue to clearly signify it is being offered under the Eclipse Contributor Agreement.
Please consider the following legal issues you’re introducing when you submit links as a proposal:
-
The phrase "this is my idea <link>" can just as easily mean "you’ve been notified you’re infringing on my idea" as it can mean "I offer this idea for inclusion."
-
Your blog or the platform that hosts your blog has its own licensing. You are likely the only one with authority to change it. No one else but you has the legal authority to copy from your blog and paste into a spec.
Proposals that are links will be rejected.