| Richard, I don't see your name in the list of committers for the
      Jakarta Messaging project. It is possible you need to be a
      committer to make these changes. (If I log out of GitHub, I see
      that I cannot edit the issue.) If you are interested, I'm quite
      sure your nomination to this group would be  welcomed. Otherwise, (apparently) any committer can update the issue. I
      added the use case label.
 -- Ed
 On 9/30/2019 6:24 PM, Richard
      Monson-Haefel wrote:
 
      
      
        I may have signed in with the wrong credentials.
          I’ll fix it tomorrow. 
        --
          
          
            Sounds like you're not a member of the team
              or not assigned correctly? 
 
              
              _______________________________________________
                Hi,
                   
 I see the fields for labels and assignment and
                    other stuff but I can't edit them.   I click on Edit
                    and they don't do anything when I click in them. 
 Richard
 
                  
                  
                    There are use case labels for some
                      time, are you able to see them?  
 
                      
                      _______________________________________________
                        Great start, David.
                           
 I submitted a user-case and plan to
                            provide a proposal but I could not find a
                            way to label the use-case I just submitted
                            (#250) as a use-case. How is that done? 
 Richard
 
                          
                          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
 _______________________________________________
 jms-dev mailing list
 jms-dev@xxxxxxxxxxx
 To change your delivery options, retrieve
                            your password, or unsubscribe from this
                            list, visit
 https://www.eclipse.org/mailman/listinfo/jms-dev
 
 
 --
 _______________________________________________
 jms-dev mailing list
 jms-dev@xxxxxxxxxxx
 To change your delivery options, retrieve your
                        password, or unsubscribe from this list, visit
 https://www.eclipse.org/mailman/listinfo/jms-dev
 
 jms-dev mailing list
 jms-dev@xxxxxxxxxxx
 To change your delivery options, retrieve your
                    password, or unsubscribe from this list, visit
 https://www.eclipse.org/mailman/listinfo/jms-dev
 
 
 --
 _______________________________________________
 jms-dev mailing list
 jms-dev@xxxxxxxxxxx
 To change your delivery options, retrieve your password,
                or unsubscribe from this list, visit
 https://www.eclipse.org/mailman/listinfo/jms-dev
 
 jms-dev mailing list
 jms-dev@xxxxxxxxxxx
 To change your delivery options, retrieve your password, or
            unsubscribe from this list, visit
 https://www.eclipse.org/mailman/listinfo/jms-dev
 
 
 
 _______________________________________________
jms-dev mailing list
jms-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jms-dev
 |