Re: GitHub repositories proposal

James,

For MNX, the co-chairs did consider this question. We concluded that we
should keep all the MNX content together in one repo for the time being,
particularly so that we can unify issue handling. Our feeling is that many
issues are likely to cross boundaries, especially in the early stages.

Note that we have a set of GitHub labels for identifying issues that belong
to one or more of the MNX areas. Contributors don't need to use them, but
they are there. The chairs will eventually label an issue if a specific
label is merited.

One final point: I don't think you've ever been asked to confine your
contributions to one single issue. What the chairs have asked for, is that
you confine your proposals for basing MNX on SVG+MIDI to a single issue,
which is #25. There's no reason you can't contribute elsewhere as long as
we're all staying within the agreed bounds of the charter.

Best,


.            .       .    .  . ...Joe

Joe Berkovitz
Founder
Noteflight LLC

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Fri, Sep 1, 2017 at 7:44 AM, Jeremy Sawruk <jeremy.sawruk@gmail.com>
wrote:

> I respectfully disagree with this proposal based on the assumptions that
> James has made. While I agree that there may be a need for separate Github
> repos (and therefore separate issue trackers), I do not agree with how he
> has selected which projects should have Github repos.
>
> Presently, the CG has three Github repos:
> - SMuFL: https://github.com/w3c/smufl
> - MusicXML: https://github.com/w3c/musicxml
> - MNX: https://github.com/w3c/mnx
>
> MusicXML remains part of the CG's agenda at least until 3.1 is finalized
> (and perhaps beyond until MNX is ready for an initial release, but that's
> not my decision). The "disagreement as to whether MusicXML can really be
> finalized" is just simply discussion about the state of MusicXML 3.1. From
> my point of view, there is no disagreement, only discussion to ensure that
> MusicXML 3.1 is released when it is ready. I personally don't see any
> blocking issues for MusicXML 3.1, but others may, and it won't be released
> until there is a group consensus.
>
> Regarding separate Github repos for MNX, CWMNX, and GMNX, I think that we
> might eventually need separate repos for CWMNX and GMNX, but I think it
> would lead to too much fragmentation if done now. I personally want to see
> MNX released, and I believe that in order to do that, the CG as a whole
> needs to focus and dedicate resources towards that goal. Having so many
> areas of discussion dilutes that focus, and makes achieving that goal
> harder and requires more time.
>
> My recommendation is to keep all of the MNX variants together until there
> is enough traction to create a separate repo for each. It's relatively easy
> to move from one repo to multiple, but it's always more difficult to manage
> multiple repos. We already have three, and I personally don't yet see the
> value of expanding this to five. Having five repos would make it more
> difficult for members to know where to file issues, and would be more
> difficult for our chair to manage.
>
> As far as your issue "that relates to GMNX (synchronization with audio
> files) without having to think about whether that issue also relates to
> CWMNX", I believe this issue relates to both CWMNX and GMNX, so it should
> continue to be an MNX issue.
>
> On Fri, Sep 1, 2017 at 4:00 AM, James Ingram <j.ingram@netcologne.de>
> wrote:
>
>> Hi all,
>>
>> This CG now has three (maybe four) completely independent topics on the
>> agenda: MNX, CWMNX, GMNX and (to judge by the present MusicXML thread)
>> maybe MusicXML as well. There seems to be some disagreement as to whether
>> MusicXML can really be finalized.
>>
>> These three (or four) topics each have their own use-cases. None of them
>> depends, for their successful development, on the successful development of
>> any of the others.
>>
>> So I'd like to propose that each of them be given its own repository on
>> GitHub. I think that would lead to less confusing, more concentrated
>> discussions and better documentation of the issues. It would be quite easy
>> to create cross-repository issue links, should that ever be necessary.
>>
>> For example, I'd like to discuss an issue that relates to GMNX
>> (synchronization with audio files) without having to think about whether
>> that issue also relates to CWMNX. If it does relate to CWMNX, then someone
>> should also raise it in the CWMNX repository. The discussions in the
>> different repositories would have little to do with each other, and be very
>> different in each case.
>>
>> If the chair doesn't want to create extra repositories, maybe you could
>> say how I should proceed. As far as I know, I'm currently only supposed to
>> contribute to mnx#25 ("GMNX should embed elements in an SVG file"), and
>> that issue is already overloaded with sub-issues.
>>
>> all the best,
>> James
>>
>> p.s. I have two other responses to the Charter Vote Comments, but they
>> can wait.
>> j
>>
>>
>