Re: MusicXML 3.1 Community Group Report available for review

Looks good to me.

On Wed, Dec 6, 2017 at 2:15 PM, Michael Good <mgood@makemusic.com> wrote:

> I think the report is easier to review when on the main gh-pages branch,
> so I have merged the pull request.
>
> The current version of the Community Report for MusicXML 3.1 is now
> available at http://w3c.github.io/musicxml/. Each change on the change
> list now contains a link to the appropriate MusicXML issue in GitHub.
>
> Please let me know if there are any other changes anyone would like to see
> in the Community Report document. I would like to add the v3.1 tag on
> GitHub later today, and then publish early next week.
>
> Best regards,
>
> Michael Good
> VP of MusicXML Technologies
> MakeMusic, Inc.
>
> On Dec 5, 2017, at 5:40 PM, Michael Good <mgood@makemusic.com> wrote:
>
> Hi Jeremy and Daniel,
>
> There is a pull request available for this change at
> https://github.com/w3c/musicxml/pull/248. Might you have a chance to
> review it? I would like to merge it tomorrow (Wednesday). If it is easier
> to review after it is merged, that’s fine too.
>
> Thanks again to both of you for this suggestion. It does make everyone
> more transparent and connected. I have added comments to issues to connect
> to pull requests and follow-on issues where needed.
>
> Best regards,
>
> Michael Good
> VP of MusicXML Technologies
> MakeMusic, Inc.
>
>
> On Dec 5, 2017, at 1:04 PM, Jeremy Sawruk <jeremy.sawruk@gmail.com> wrote:
>
> Yes, that is exactly what I had in mind. I also think that putting the
> issue numbers at the end of the issue is more readable.
>
> On Tue, Dec 5, 2017 at 4:02 PM, Michael Good <mgood@makemusic.com> wrote:
>
>> Hi Jeremy,
>>
>> Thank you for this suggestion. We did keep the link to the complete list
>> of issues addressed in 3.1 at the end of the document. I believe you are
>> suggesting that we link individual changes to individual issues. Daniel had
>> suggested something similar.
>>
>> How would you suggest these links look in the change list? Would you want
>> something like:
>>
>>
>>    - The except-voice element is used to specify a combination of slash
>>    notation and regular notation. (Issue 231
>>    <https://github.com/w3c/musicxml/issues/231>)
>>
>>
>> Or did you have some other formatting in mind? I saw another spec that
>> had the issue numbers at the start of each bullet item, but that seems less
>> readable to me.
>>
>> Best regards,
>> Michael
>>
>> On Dec 5, 2017, at 11:00 AM, Jeremy Sawruk <jeremy.sawruk@gmail.com>
>> wrote:
>>
>> Thank you for making this report. I think this is an extremely useful
>> document, and something that should be included with every release.
>>
>> I have one minor suggestion:
>>
>> Link to related Github issues. This will help track changes, as well as
>> link to source code, discussion, and other relevant information. This way
>> we can have both linking to technical discussion as well as user-friendly
>> descriptions. Re-reading Peter's email, he felt that linking to Github was
>> insufficient, and I agree. However, I think it would be helpful to have
>> both.
>>
>>
>> On Tue, Dec 5, 2017 at 1:41 PM, Michael Good <mgood@makemusic.com> wrote:
>>
>>> Hello all,
>>>
>>> A new version of the MusicXML 3.1 Community Group Report incorporating
>>> Peter Deutsch’s request for a full change list is now available for review
>>> at https://w3c.github.io/musicxml/.
>>>
>>> Any further reviews this week would be most appreciated. The current
>>> plan is to create the v3.1 tag in GitHub later today so the schema link
>>> starts working, and then publish the report early next week.
>>>
>>> Best regards,
>>>
>>> Michael Good
>>> VP of MusicXML Technologies
>>> MakeMusic, Inc.
>>>
>>>
>>
>>
>
>
>