Good points.
While the java.net JIRA does not offer all different issue types one can
find on other platforms (e.g. Apache) those available can be used well.
Being a long term Agile coach and advocate (I gave a presentation about it
at JavaOne unconference in 2010, long before it officiallly became "hip"
and an Agile trak was added last year;-) I also use the JIRA Scrum boards
for JSR 363, see the EDR sprint:
https://java.net/jira/secure/RapidBoard.jspa?rapidView=12&view=reporting&chart=sprintRetrospective&sprint=23
So even if one wouldn't use all of that, there's value defining Stories or
Epics in JIRA IMHO, but the java.net Wiki might do if preferred.
Some JSRs like CDI and others use vast threads in the mailing list, but
IMHO that easily gets messy and clutters mail boxes of users, so JIRA still
transparent (see reports like my example) is less straining on the email
accounts of most EG members.
Cheers,
Werner
On Mon, Mar 9, 2015 at 9:52 PM, Les Hazlewood <les_at_stormpath.com> wrote:
> Hi all,
>
> Where is discussion of design and features to be done? I see many Jira
> issues (presumably that are up for discussion), and thoughts/concepts in
> emails. Should we discuss as Jira comments? Or email thread posts? It is
> not immediately clear as to which approach we should take. Also, one could
> think of a wiki page as being used to organize various topics and
> sub-topics to help focus discussions as well as to get a high level picture
> of the general state of things.
>
> What is the recommended process we should follow so don't have to look in
> multiple sources?
>
> If I think feature X should be represented, how would that come to
> fruition? For example:
>
> 1. A wiki page with a hierarchical table of contents. Each item in the
> TOC represents a feature/item to be discussed. Put an item in the TOC (in
> the appropriate category) if you'd like it discussed.
>
> 2. Discuss the item by bringing it up on the mailing list. If it is
> believed to warrant design/implementation work, create a Jira issue
> representing the task.
>
> 3. The EG, on the mailing list, discusses various pros/cons of the Jira
> issue. Whatever the outcome, the Jira issue should reflect it (resolution
> status) and reference the mailing list discussion.
>
> 4. Update the wiki page as features/issues are added/closed/removed.
> Perhaps things that are considered not in scope just get a line through
> them and are not removed so that it is obvious that a feature has already
> been discussed (leading to less duplicates), etc.
>
> This is just brainstorming off the top of my head - I'm not necessarily
> suggesting a specific course of action - just that this is one of many ways
> of thinking about this stuff.
>
> It seems obvious to me that there needs to be a 'big picture' wiki page
> that represents all the topics and sub-topics/issues that are being
> addressed, and each sub-topic can be detailed as children wiki pages, and
> actionable items are represented as Jira issues.
>
> How do you guys recommend we go about doing this so we're all on the same
> page and so we don't duplicate effort?
>
> Side note: have you heard of Documentation Driven-Development? I'm not
> advocating that we take that approach, just that for a spec committee, it
> seems like an interesting approach to focus efforts and keep things
> organized along the way.
>
> Thoughts?
>
> Cheers,
>
> Les
>