jsr375-experts@javaee-security-spec.java.net

[jsr375-experts] Re: EG logistics

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Mon, 9 Mar 2015 22:41:13 +0100

Hi,

On Mon, Mar 9, 2015 at 10:37 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> 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.

It's not always that messy IMHO, but we should be careful to not
discuss everything in one thread and split off topics to their own
threads as soon as the need arises. Then it keeps clear what's being
discussed and what's being decided about.

Sometimes it also helps not to have too many discussions going on in
parallel, but this depends.

Kind regards,
Arjan Tijms



>
> 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
>
>