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