Hi,
Quoting Les' comment earlier in the thread:
"I think creating Jira issues before a high level outline or 'epics' or
'stories' (or 'topics' and 'sub topics') are defined is backwards.
Shouldn't we all be on the same page and have an understanding of the
higher level picture and (general) topics/sub-topics before we go
debating specific features and tasks? The JSR is a good start, but too
high level, and Jira issues are too low level (IMHO). More, they are
myopic: when looking at a single jira issue, I can't see how it relates
to other issues, where it aligns with other issues in its 'category', or
where it fits in the general scheme of things."
I agree with him. I think a top-down approach of first understanding the
higher level picture, which leads to specific features, which leads to
tasks, which then translates to Spec/RI/TCK work seems to make sense.
And I do not mean a "big upfront design". I guess I mean start with a
description of the problem and a description of the solution, then work
from there.
I also see Arjan's point that some of the Security API work could be a
"collection of utility methods that taken all
together fill a lot of holes", perhaps implying a collection of JIRA
issues may be sufficient in some cases.
But, I think one needs an easy and descriptive way to relate the general
problem category to the specific JIRAs. This would also provide an easy
way for those unfamiliar with the ongoing discussions to "on ramp" into
the work we have done.
What do you think of what the CDI spec team has done here:
http://www.cdi-spec.org/ Specifically, their "Working Method" as
mentioned here
http://www.cdi-spec.org/news/2014/10/06/CDI-20_working_method/ seems to
fit what was discussed on this thread.
The CDI home page is a wiki with a table called "Work Status" which
serves as the starting point to navigate their work. Work is divided
into "Workshops", which correlate to Epics. The Doc Link for each
Workshop points to a Google document, which is "a draft document
describing the global idea". The Google document is collaboratively
commented/updated. Each adopted concept on the Google Doc becomes one or
more JIRA tasks, which leads to more detailed discussion. The JIRA tasks
point back to the Google Doc using an Epic. Completed tasks translate
into spec/RI/TCK updates.
This seems to be the typical JIRA flow, with Epics associated with
shared Google docs, which are referenced from a central wiki table.
We can use java.net wiki to create a similar "Work Status" home page. I
think the only concern about the Google Docs is that only EG members may
update the docs due to the JCP licensing, whereas all may view the doc.
We could continue to use the Experts mailing list for discussions, and
perhaps employ a Subject prefix which includes a JIRA or EPIC reference
to map the mail thread back to the discussed JIRA or EPIC.
=======
What do you think? I am really open to any tool that we are "allowed" to
use, but it seems we can pretty easily accomplish a transparent workflow
using java.net, JIRA and Google Docs. One hole in this process is code
review tools, more on that on the Code Repository thread.
Thanks,
Alex
On 3/9/15 6:28 PM, arjan tijms wrote:
> Hi,
>
> On Mon, Mar 9, 2015 at 10:49 PM, Les Hazlewood<les_at_stormpath.com> wrote:
>> I think creating Jira issues before a high level outline or 'epics' or
>> 'stories' (or 'topics' and 'sub topics') are defined is backwards.
>> Shouldn't we all be on the same page and have an understanding of the higher
>> level picture and (general) topics/sub-topics before we go debating specific
>> features and tasks?
> It depends really, in some cases you want to have some big upfront
> design to see the bigger picture and it other cases you don't.
>
> In the (somewhat) lengthy discussion in
> https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-10 I indeed
> mentioned at some point:
>
> "I do think it's especially important to establish some terminology
> and to take a look at how all individual ideas come together as a
> whole."
>
> In other cases, a collection of small requirements does give you an
> idea of where to go.
>
> For instance, "authentication events" is by itself a pretty clear wish
> IMHO, and that those events should be observable by CDI is pretty
> clear too. Now the details of who is going to throw the event exactly
> are still to be discussed, as are details regarding what the event
> looks like, and whether a listener can or cannot influence the
> authenticate outcome etc.
>
> For what it's worth, OmniFaces simplified JSF without much if any
> upfront designs. It's a collection of utility methods that taken all
> together fill a lot of holes in the JSF spec and arguably makes JSF a
> lot more fun to use.
>
> I think a lot of the security problems can be solved in that way as
> well. For instance, one problem is that the user/caller and
> group/roles Principals in Java EE are not standardized. So lets look
> at defining two standard principals for that. Another problem is that
> asking the question "Will the user have access to this URL?" requires
> a lot of code. So let's introduce a small utility method for that very
> question so it's just one call. Etc etc.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
> The JSR is a good start, but too high level, and Jira
>> issues are too low level (IMHO). More, they are myopic: when looking at a
>> single jira issue, I can't see how it relates to other issues, where it
>> aligns with other issues in its 'category', or where it fits in the general
>> scheme of things.
>>
>> In other words, Jira is an issue tracker - it is marginal at best for
>> feature management (whereas, Confluence - as just one of many examples - is
>> better for that).
>>
>> My .02,
>>
>> Les