This has the same central command-control issue. I suggest just working on an individual EG basis and coordinate informally. The official way would be through the Java EE EG and spec leads. Frankly that might be more overhead than it is worth.
> On Mar 1, 2016, at 4:57 AM, Werner Keil <werner.keil_at_gmail.com> wrote:
>
> Depending on the JSR that is often done in one place (especially since "asciidoc" where chosen for the Spec is simply another folder under a Maven or Gradle structure) but to make it easier to only build API or Spec, it's certainly possible. At least in JSR 354 the default build chain for the Java SE 8 API usually builds the spec, too every time the API is generated.
>
> I copied Reza (not sure, if he's also on the EG mailing list here) since he could point you/us to the right people at Oracle/JCP for that. I suggested on previous occasions, that several of these best practices should also go into something like the "Spec Lead Guide". Maybe we can help to get some of these documented for new Spec Leads to make their lives and that of their expert groups easier;-)
>
> Kind Regards,
> Werner
>
>> On Tue, Mar 1, 2016 at 10:47 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>> Hi,
>>
>> Okay, I'm convinced ;) Let's drop the uber repo idea.
>>
>> Coherent naming conventions would still be a good idea I guess. E.g.
>>
>> https://github.com/[SPEC-NAME]-spec
>> /[SPEC-NAME]-proposals
>> /[SPEC-NAME]-examples
>> /[SPEC-NAME]-API
>> /[RI-NAME]
>>
>> What about a separate repo for the spec document, or put it in /[SPEC-NAME]-API?
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>> On Tue, Mar 1, 2016 at 10:04 AM, Werner Keil <werner.keil_at_gmail.com> wrote:
>>> Hi,
>>>
>>> My "50 cent" from running or helping a few rather succesful JSRs like 354 or 363 on GitHub.
>>> The one orga per JSR strategy sounds better. GitHub has a very distinct and good memory. Every PR you merge makes the person who raised it a "contributor" to that codebase. Before JSR 364/EC even made sure, that type of member even exists (it should be when 364 goes final) Thus in a "Uber orga" for all of Java EE it would be much harder to follow who is in what EG and who isn't if there are PRs.
>>>
>>> Werner
>>>
>>>> On Tue, Mar 1, 2016 at 7:55 AM, Ivar Grimstad <ivar.grimstad_at_gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I agree. The limitation in GitHub that only allows for one github pages site per org/account also favors separate orgs.
>>>>
>>>> Regarding migrate the spec from word to asciidoc, what if we set up the structure at JavaLand next week and start to migrate section for section. The we can encourage the community to help by converting a part and sending PRs? Just a thought... there's a *lot* of pages...
>>>>
>>>> Ivar
>>>>
>>>>
>>>>> On Mon, Feb 29, 2016 at 11:51 PM David Blevins <dblevins_at_tomitribe.com> wrote:
>>>>> Hello from an airport!
>>>>>
>>>>> Chiming in to show support for the proposal. In reference to one big org for all of EE, I'd be in favor of separate orgs to
>>>>>
>>>>> 1) give spec leads the most control. Aggregating control/authority to a center usually slows things down.
>>>>>
>>>>> 2) more closely matches current java.net org for easier migration
>>>>>
>>>>> That said there still could be a javaee repo with forks of the other repos. Though perhaps not worth the overhead.
>>>>>
>>>>> The other item that would be great to see is converting the word spec to asciidoc using the same setup as CDI
>>>>>
>>>>> -David
>>>>>
>>>>>> On Monday, February 29, 2016, Ivar Grimstad <ivar.grimstad_at_gmail.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> What do you think of using this unfortunate "quiet period" to move from Subversion to Git?
>>>>>>
>>>>>> The way the java.net svn repo is organized does not allow for easy migration to Git, but here is a suggestion that should be feasible:
>>>>>> Migrate the jms2.1 folder to a new Git repository as the master branch.
>>>>>> Migrate the www folder to a new Git repository (separate from the above)
>>>>>> Keep the rest in the Subversion repo as is
>>>>>> Why GitHub and not java.net?
>>>>>> GitHub offers better support for collaboration and pull requests
>>>>>> I don't have access to create repositories on java.net
>>>>>> The future of java.net is uncertain (rumor has it...)
>>>>>> When and if we have a java.net Git repo, we can move everything there, treat as master and use the GitHub repo as a mirror.
>>>>>> Any objections? Or suggestions otherwise?
>>>>>> I will be happy to fix this and for the purpose I have created a GitHub group/organization:
>>>>>> (we have done the same thing with JSR 371 and JSR 375)
>>>>>>
>>>>>> https://github.com/jms-spec
>>>>>>
>>>>>> I will add all of you to this group if I can find your github user. Please email me your username if you don't get an invitation.
>>>>>>
>>>>>> Ivar
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sent from Gmail Mobile
>>>
>>
>