Hi,
On Mon, Mar 9, 2015 at 9:52 PM, Les Hazlewood <les_at_stormpath.com> wrote:
> 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?
The way that the process is mostly carried out in the other EGs is
that JIRA issues are created, which are then discussed on the EG
mailing list.
At least for JSR 372 (JSF 2.3) after a certain level of consensus is
reached someone then does an implementation of the idea and attaches
this as a changebundle to the JIRA issue, after which everyone gets a
chance to look at said implementation. If no one has any objections,
the changebundle is then committed to the repository by the spec lead
or co-sped lead.
Maybe its helpful to look at the introduction mail of that EG:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr372-experts/archive/2014-09/message/0
Here's a (hopefully) clear example of the JIRA issue, followed by a
discussion, a changeset, a vote of sorts and finally the commit of the
code and creation of text for the spec document:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr372-experts/archive/2015-02/message/44
Not every EG follows the exact same steps, but in broad lines I think
they do. Some differences are that the CDI EG for example has a
periodic scheduled IRC chat, while the JSF EG doesn't have that. The
CDI EG also now and then puts documents with technical designs up on
Google docs, where others can comment on it and/or make corrections.
I do think the IRC chat is particularly convenient.
In the welcome mail a web conference was proposed. I'm not 100% sure
if that refers to a voice teleconference, but if it does then I have
to say that from personal experience I'm not a big fan of that. Voice
over the Internet remains a sub-optimal thing, especially when many
parties are involved. Call-in is almost always to an American number,
which may not be possible/allowed to dial for people who happen to be
at their office. And seeing that we're such an international team,
accents may make it extra difficult to hear what's being said via
communication lines that are already low quality. Just my 2 cents ;)
Kind regards,
Arjan Tijms
> 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?
>on t
> 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