GitHub (including Gitter, etc.) would only make sense, if it's used here at
least as an auto-synced mirror.
JIRA (though some JSRs stick to the GitHub issue tracker, too) is provided
as soon as you got a java.net project, which already exists (and so do some
tickets, probably not all of them created with the best category, but in
the absence of "requirement" I guess "Improvement" was as good as it gets
for those who wrote the first issues;-)
Some existing items in JIRA were created hasty it seems, I would have at
least put proper tag like "question" to
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-6
Werner
On Mon, Mar 9, 2015 at 10:55 PM, Les Hazlewood <les_at_stormpath.com> wrote:
> I tend to use github or gist for code samples that don't format well (and
> only when they don't format well) in mailing lists. Using an issue tracker
> for design discussions because it formats better is not a good idea IMO; it
> muddies the water of where discussions should be held and requires people
> to go back and forth across various sources - which is the exact thing I'm
> trying to eliminate in this discussion :)
>
> Les
>
> On Mon, Mar 9, 2015 at 2:50 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
>
>> Well unless absolutely necessary it seems a good practice to keep
>> suggested code snippets in a place like JIRA (where formatting works rather
>> well) instead of cluttering email conversations in the mailing list. That
>> is what sometimes disturbs other project's (not just JSRs) mailing lists if
>> practiced a lot. The mailing list doesn't format these things well, even
>> worse if quoted messages copy it over and over again.
>>
>> For decision making or other discussions the mailing list can work well
>> if used with care. If we used Github at least for some repositories or as
>> mirror, the recent addition of Gitter may provide slightly more realtime,
>> yet persistent discussion forum. We started using it in JSRs like 354, 363
>> or the newly created 377. Since it offers the same markup as GitHub, it
>> feels more powerful than say IRC or other chats.
>>
>> Regards,
>> Werner
>>
>> On Mon, Mar 9, 2015 at 10:41 PM, arjan tijms <arjan.tijms_at_gmail.com>
>> wrote:
>>
>>> 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
>>> >
>>> >
>>>
>>
>>
>