I'm happy to continue with asciidoc if that's the EG's preference,
especially since it's already started that way on GitHub. Google docs
does seem a little easier to collaborate with, though, and to export
from in different formats.
Arjan, thanks for volunteering to contribute to the "authentication
mechanism" and "identity store" sections.
Werner, do let us know how zoom works for you; that might be a good tool
for meetings.
Will
On 10/25/2016 12:38 PM, Werner Keil wrote:
> Hi,
>
> I am fine with either of those. JSR 354
> https://github.com/JavaMoney/jsr354-api/tree/master/src/main/asciidoc
> <https://github.com/JavaMoney/jsr354-api/tree/master/src/main/asciidoc>
> shows, how this could look like in a Final release using Asciidoc.
> And as Alex mentioned, Bean Validation and CDI also use it (with a few
> tweaks, e.g. finer-grained modularity JSR 363 took some inspiration
> from the CDI TCK, but unless we could get that to be Open Sourced in
> 375, I'm not sure, if it's an option here?;-)
>
> JSR 363
> (https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg_QlANT92_lhxUWO2gCY/edit
> <https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg_QlANT92_lhxUWO2gCY/edit>)
> did use Google Docs for the Spec. There was some issue with the
> formatting of Asciidoc which I evaluated, but we had some initial
> material from JSR 275 or the UoM.org project as contributions to the
> spec which did not render well in Asciidoc. While importing those into
> Google Docs worked fine, that was the main reason. JSR 107 (with
> Oracle as Co Spec Lead) also used Google Docs.
>
> For a fresh start with no major import from existing documents, I
> guess Asciidoc works pretty well.
>
> If we continue to use GitHub at least as mirror (or if there's no
> permanent replacement or life extension to java.net <http://java.net>
> after Spring '17) then Gitter is worth a thought for a more persistent
> form of instant messaging:
> https://gitter.im/unitsofmeasurement/unit-ri?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge
> <https://gitter.im/unitsofmeasurement/unit-ri?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge>
> also see JSR 363 RI, we used it later in 354, so there is less history
> there.
>
> Slack would be an alternative, I'm sure most of you joined channels
> e.g. by Adam Bien (also in this EG;-) or similar.
> HipChat was used by a client last year even inside the corporate
> firewalls (as one of the very few "cloud-based" solutions that really
> does store its data outside the country;-)
>
> Not sure about preferences and policies by Oracle, but especially
> Gitter seems rather easy for GitHub repo owners and admins to add.
>
> We do use Google Hangouts in other cases. JSR 363 rarely did, but we
> had the advantage of 3-4 EC members also in the EG so we met 2-3 times
> per year for a F2F. JSON-B/P Spec Lead Dmitry just invited us to a
> Zoom voice call https://oracle.zoom.us
> <https://oracle.zoom.us/my/dmitry.kornilov> tonight. We'll see how it
> goes, but it looks like it is officially ordered by Oracle, so if e.g.
> it also records sessions, it may be worth a try even if some may not
> be able to join. A history function similar to those persistent chats
> would be a great advantage. I'll know more after tonight how Zoom works.
>
> Regards,
> Werner
>
>
> On Tue, Oct 25, 2016 at 6:14 PM, Alex Kosowski
> <alex.kosowski_at_oracle.com <mailto:alex.kosowski_at_oracle.com>> wrote:
>
> Hi,
>
> +1
>
> One big advantage of a text-based chat from a spec lead
> perspective is that it is self-documenting :)
>
> Alex
>
>
> On 10/25/16, 12:09 PM, arjan tijms wrote:
>> Hi,
>>
>> Live meetings (being voice or video based) would not be my first
>> preference, but a text based chat would people still be
>> interested would not be that bad. For now I think we can move
>> forward via email.
>>
>> As for the draft document, Alex had already set something up
>> here:
>> https://github.com/javaee-security-spec/spec-api/tree/master/spec/src/main/doc
>> <https://github.com/javaee-security-spec/spec-api/tree/master/spec/src/main/doc>
>>
>> For the tool/format asciiDoc was chosen back then. I think that
>> would certainly still be a viable option. The sections are
>> currently mostly empty, as it's just a setup really. I think I
>> could contribute to the "authentication mechanism" and "identity
>> store" sections, at least put the general gist there.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>> On Tue, Oct 25, 2016 at 5:35 PM, Will Hopkins
>> <will.hopkins_at_oracle.com <mailto:will.hopkins_at_oracle.com>> wrote:
>>
>> Hi All,
>>
>> Sorry for my silence the last we or so, I was catching up on
>> some other work.
>>
>> On reflection, and given timezone differences, I'm not sure a
>> "live" meeting makes much sense -- we should be able to move
>> forward by email.
>>
>> I think the most important next step is to create the early
>> draft. Looks like 11/29 is the date by which we need that
>> submitted.
>>
>> To that end, a few people volunteered to work on particular
>> sections -- that will be very helpful. I will create the main
>> document itself, contribute what I can for sections without
>> assigned authors, and update with material that others
>> produce. I'm looking into what tool to use; Google docs might
>> be the right answer -- it certainly facilitates review and
>> collaboration -- but it's somewhat limited in terms of
>> formatting.
>>
>> For those willing to contribute a particular section, please
>> respond to this indicating which section(s) you're interested
>> in authoring.
>>
>> Thanks,
>>
>> Will
>>
>> --
>> Will Hopkins | Platform Security Architect | +1.781.442.0310
>> <tel:%2B1.781.442.0310>
>> Oracle Cloud Application Foundation
>> 35 Network Drive, Burlington, MA 01803
>>
>>
>
--
Will Hopkins | Platform Security Architect | +1.781.442.0310
Oracle Cloud Application Foundation
35 Network Drive, Burlington, MA 01803