Handling spec writing process @ GitHub

newer
Agenda for UMA telecon 2015-09-03...

Maciej Machulak

27 Aug 2015 27 Aug '15

8:39 p.m.

Hi, It was discussed today how the current process of spec editing looks like on GitHub (currently the spec is here: https://github.com/KantaraInitiative/wg-uma). All the changes are done on this repository, some via branches and some directly to the master branch. It was suggested that maybe we could use distributed repos (each editor would have a fork of the repo) and changes to the main repo would be done via pull requests. While I agree that using pull requests is best practice, I think we could do without this for UMA spec editing. The current setup which we have is pretty low overhead and sufficient for our needs (we could probably improve on using branches but that's also not something we have to strictly stick to). However, I'd like to hear the opinion of others. Let me know so that we can act accordingly. Maciej -- Maciej Machulak email: maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL)

Attachments:

attachment.html (text/html — 1.2 KB)

Show replies by date

Maciej Machulak

2 Sep 2 Sep

2:14 a.m.

Hi all, I refer to my earlier email - any comments? :-) Thanks! Maciej On 27 August 2015 at 22:39, Maciej Machulak wrote:

...

Hi,

It was discussed today how the current process of spec editing looks like on GitHub (currently the spec is here: https://github.com/KantaraInitiative/wg-uma). All the changes are done on this repository, some via branches and some directly to the master branch. It was suggested that maybe we could use distributed repos (each editor would have a fork of the repo) and changes to the main repo would be done via pull requests.

While I agree that using pull requests is best practice, I think we could do without this for UMA spec editing. The current setup which we have is pretty low overhead and sufficient for our needs (we could probably improve on using branches but that's also not something we have to strictly stick to).

However, I'd like to hear the opinion of others. Let me know so that we can act accordingly.

Maciej

-- Maciej Machulak email: maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL)

-- Maciej Machulak email: maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL)

Justin Richer

2:24 a.m.

The overhead associated with fully distributed development when there is a clear core team is not worth the headaches it can cause, especially since nobody that I can see would be taking the job of patch integrator to manage all the pull requests. Having an editor create a pull request and then merge it themselves into the main repository is just a waste of that editor’s time. Only primary editors should have write access to the repository and should be allowed to make changes directly to it. Things that are WG consensus should go on “master” (or the appropriate version-tracked major branch), proposed solutions and text by the primary editors should go on branches in the main repository and brought to the group for feedback. Non-editors (like myself) can fork the repository, branch, and create either pull requests or simply reference commits and issues from there. — Justin

...

On Sep 1, 2015, at 10:14 PM, Maciej Machulak wrote:

Hi all,

I refer to my earlier email - any comments? :-) Thanks!

Maciej

On 27 August 2015 at 22:39, Maciej Machulak mailto:maciej.machulak@gmail.com> wrote: Hi,

It was discussed today how the current process of spec editing looks like on GitHub (currently the spec is here: https://github.com/KantaraInitiative/wg-uma https://github.com/KantaraInitiative/wg-uma). All the changes are done on this repository, some via branches and some directly to the master branch. It was suggested that maybe we could use distributed repos (each editor would have a fork of the repo) and changes to the main repo would be done via pull requests.

While I agree that using pull requests is best practice, I think we could do without this for UMA spec editing. The current setup which we have is pretty low overhead and sufficient for our needs (we could probably improve on using branches but that's also not something we have to strictly stick to).

However, I'd like to hear the opinion of others. Let me know so that we can act accordingly.

Maciej

-- Maciej Machulak email: maciej.machulak@gmail.com mailto:maciej.machulak@gmail.com mobile: +44 7999 606 767 tel:%2B44%207999%20606%20767 (UK) mobile: +48 602 45 31 66 (PL)

-- Maciej Machulak email: maciej.machulak@gmail.com mailto:maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Dazza Greenwood

4 a.m.

Ok - since you asked twice. I'll bit. Yes, please get on board and use branches along the lines Justin has been explaining. The practice of branching is very good and I hope to see it catch on for UMA. In addition to being efficient and effective as a work style, consider the accountability, transparency and due process implications of what Justin just wrote: "Things that are WG consensus should go on “master” (or the appropriate version-tracked major branch), proposed solutions and text by the primary editors should go on branches in the main repository and brought to the group for feedback." When that feedback loop is tied to enumerated issues things can go smoothly, fairly and very effectively. If the group changes its mind later it is dead easy to roll back the whole project to that moment and have a solid foundation for correcting issues or making different choices. This makes the project easier to be understood by those who are less involved or need to get up to speed later. The refined functionality for looking backwards and keeping up to speed is reason enough to adopt these practices but the most powerful capability is how this method allows groups of any size to coherently live into their own future. I'm working hard on a legal project now that has a "timeline slider" enabling users to roll the calendar forward and see the expected state of effective law at that date. The law is just another UTF-8 encoded file in just another Git repo and and the text of statutory or regulatory provisions that will have expired (eg "sunset" etc) would not appear in the file. Conversely, the text of currently enacted but not yet "effective" provisions that will have become active by that date will appear in the file. Because the file would exist in a branch designated for a future release of the code - a future version of the legal code. Seeing our current definite agreed state of how an entire code base is planned to look at given time is very very handy. And it seems to be a very very hard thing for most people to conceptualizer or represent with more traditional information organization and representation methods. In fact, people are usually confused about what things, as a whole, are planned to look like at a point in the future and yet many current decisions hinge on just that. This capability of designating branches for future releases affords a high value and highly intelligent capacity for groups to prioritize, sequence and build toward key future decisions. While only the trusted project leaders should be empowered to make the changes (as Jason indicated) this practice still enables direct access to the best then current thinking and a surface area to make contributions that are best handled now and also contributions that build out or improve major planned or proposed future work. The use of branching for members to make direct contributions is not only democratizing it is also smart allocation of available resources so everybody can actually contribute directly via pull requests. There is a learning curve to this, to be sure, but not an especially big curve. Given how perfect a fit GitHub (specifically the free, public GitHub service not just the Git protocol) is for consensus document oriented groups like standards organizations and law making bodies I'm increasingly surprised everybody isn't using it and taking advantage of the very basic group collaborative work methods Justin has been describing. GitHub is so fully documented and widely used by technical and non-technical populations at this point it seems that the main obstacle is just aversion to change. That is certainly true in legal circles but just today a City of Boston employee proudly showed be about 20 new and very active GitHub repos in the city's organization including a wide range of projects and types of city workers (even a lawyer). Most of these were still private due to the data or other issues but many are coming online publicly and this trend is definitely sweeping the nation and the world. I hope to see UMA get with this program. Thanks, - Dazza | Sent from my iPhone | Please Forgive Typos _________________ | Dazza Greenwood, JD | CIVICS.com, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza@CIVICS.com | Biz: http://CIVICS.com | MIT: https://law.MIT.edu | Me: DazzaGreenwood.com | Twitter: @DazzaGreenwood | Google+: google.com/+DazzaGreenwood | LinkedIn: linkedin.com/in/DazzaGreenwood | GitHub: github.com/DazzaGreenwood/Interface

...

On Sep 1, 2015, at 10:24 PM, Justin Richer wrote:

The overhead associated with fully distributed development when there is a clear core team is not worth the headaches it can cause, especially since nobody that I can see would be taking the job of patch integrator to manage all the pull requests. Having an editor create a pull request and then merge it themselves into the main repository is just a waste of that editor’s time.

Only primary editors should have write access to the repository and should be allowed to make changes directly to it. Things that are WG consensus should go on “master” (or the appropriate version-tracked major branch), proposed solutions and text by the primary editors should go on branches in the main repository and brought to the group for feedback.

Non-editors (like myself) can fork the repository, branch, and create either pull requests or simply reference commits and issues from there.

— Justin

...
On Sep 1, 2015, at 10:14 PM, Maciej Machulak wrote:

Hi all,

I refer to my earlier email - any comments? :-) Thanks!

Maciej

...
On 27 August 2015 at 22:39, Maciej Machulak wrote: Hi,

It was discussed today how the current process of spec editing looks like on GitHub (currently the spec is here: https://github.com/KantaraInitiative/wg-uma). All the changes are done on this repository, some via branches and some directly to the master branch. It was suggested that maybe we could use distributed repos (each editor would have a fork of the repo) and changes to the main repo would be done via pull requests.

While I agree that using pull requests is best practice, I think we could do without this for UMA spec editing. The current setup which we have is pretty low overhead and sufficient for our needs (we could probably improve on using branches but that's also not something we have to strictly stick to).

However, I'd like to hear the opinion of others. Let me know so that we can act accordingly.

Maciej

-- Maciej Machulak email: maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL)

-- Maciej Machulak email: maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler

4:05 a.m.

This makes sense to me. I think James brought up using branches for everything just because he’s involved in insanely large projects. :-) We didn’t actually conclude our discussion of whether to “close” the repo in order to look after IP hygiene, but it sort of relates to this topic. (Though pull requests from random non-participant strangers can always be put aside; it’s more the issue discussions that we were asking about). Eve

...

On 1 Sep 2015, at 7:24 PM, Justin Richer wrote:

The overhead associated with fully distributed development when there is a clear core team is not worth the headaches it can cause, especially since nobody that I can see would be taking the job of patch integrator to manage all the pull requests. Having an editor create a pull request and then merge it themselves into the main repository is just a waste of that editor’s time.

Only primary editors should have write access to the repository and should be allowed to make changes directly to it. Things that are WG consensus should go on “master” (or the appropriate version-tracked major branch), proposed solutions and text by the primary editors should go on branches in the main repository and brought to the group for feedback.

Non-editors (like myself) can fork the repository, branch, and create either pull requests or simply reference commits and issues from there.

— Justin

...
On Sep 1, 2015, at 10:14 PM, Maciej Machulak mailto:maciej.machulak@gmail.com> wrote:

Hi all,

I refer to my earlier email - any comments? :-) Thanks!

Maciej

On 27 August 2015 at 22:39, Maciej Machulak mailto:maciej.machulak@gmail.com> wrote: Hi,

It was discussed today how the current process of spec editing looks like on GitHub (currently the spec is here: https://github.com/KantaraInitiative/wg-uma https://github.com/KantaraInitiative/wg-uma). All the changes are done on this repository, some via branches and some directly to the master branch. It was suggested that maybe we could use distributed repos (each editor would have a fork of the repo) and changes to the main repo would be done via pull requests.

While I agree that using pull requests is best practice, I think we could do without this for UMA spec editing. The current setup which we have is pretty low overhead and sufficient for our needs (we could probably improve on using branches but that's also not something we have to strictly stick to).

However, I'd like to hear the opinion of others. Let me know so that we can act accordingly.

Maciej

-- Maciej Machulak email: maciej.machulak@gmail.com mailto:maciej.machulak@gmail.com mobile: +44 7999 606 767 tel:%2B44%207999%20606%20767 (UK) mobile: +48 602 45 31 66 (PL)

-- Maciej Machulak email: maciej.machulak@gmail.com mailto:maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Eve Maler

4:07 a.m.

Oh sorry, you did address closing the repo. I think we can only execute on “Only primary editors should have write access to the repository and should be allowed to make changes directly to it” if we do that, and it will have the same effect on the issues, iirc. Eve

...

On 1 Sep 2015, at 9:05 PM, Eve Maler wrote:

This makes sense to me. I think James brought up using branches for everything just because he’s involved in insanely large projects. :-)

We didn’t actually conclude our discussion of whether to “close” the repo in order to look after IP hygiene, but it sort of relates to this topic. (Though pull requests from random non-participant strangers can always be put aside; it’s more the issue discussions that we were asking about).

Eve

...
On 1 Sep 2015, at 7:24 PM, Justin Richer mailto:jricher@mit.edu> wrote:

The overhead associated with fully distributed development when there is a clear core team is not worth the headaches it can cause, especially since nobody that I can see would be taking the job of patch integrator to manage all the pull requests. Having an editor create a pull request and then merge it themselves into the main repository is just a waste of that editor’s time.

Only primary editors should have write access to the repository and should be allowed to make changes directly to it. Things that are WG consensus should go on “master” (or the appropriate version-tracked major branch), proposed solutions and text by the primary editors should go on branches in the main repository and brought to the group for feedback.

Non-editors (like myself) can fork the repository, branch, and create either pull requests or simply reference commits and issues from there.

— Justin

...
On Sep 1, 2015, at 10:14 PM, Maciej Machulak mailto:maciej.machulak@gmail.com> wrote:

Hi all,

I refer to my earlier email - any comments? :-) Thanks!

Maciej

On 27 August 2015 at 22:39, Maciej Machulak mailto:maciej.machulak@gmail.com> wrote: Hi,

It was discussed today how the current process of spec editing looks like on GitHub (currently the spec is here: https://github.com/KantaraInitiative/wg-uma https://github.com/KantaraInitiative/wg-uma). All the changes are done on this repository, some via branches and some directly to the master branch. It was suggested that maybe we could use distributed repos (each editor would have a fork of the repo) and changes to the main repo would be done via pull requests.

While I agree that using pull requests is best practice, I think we could do without this for UMA spec editing. The current setup which we have is pretty low overhead and sufficient for our needs (we could probably improve on using branches but that's also not something we have to strictly stick to).

However, I'd like to hear the opinion of others. Let me know so that we can act accordingly.

Maciej

-- Maciej Machulak email: maciej.machulak@gmail.com mailto:maciej.machulak@gmail.com mobile: +44 7999 606 767 tel:%2B44%207999%20606%20767 (UK) mobile: +48 602 45 31 66 (PL)

-- Maciej Machulak email: maciej.machulak@gmail.com mailto:maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com mailto:xmlgrrl@gmail.com

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Justin Richer

2:18 p.m.

I would strongly recommend *against* closing the issue tracker. If you had done so before, I wouldn’t have been able to submit *any* of the issues that I had. Don’t stand in the way of well meaning people who want to make contributions. :) I’m not a lawyer, but I’ve dealt with this in other venues. In software, generally, reported issues in a public tracker like this are considered contributions, and not all contributions covered by whatever licensing the codebase has. And since the issues do not directly affect the codebase (even pull requests) but have to go through a core contributor’s hands, there’s a gating system built in. You can also put a notice to this effect (like the IETF Note Well or a software project’s LICENSE file) in the main project that the issue tracker is attached to. We’re doing something like this with COSE: https://github.com/cose-wg/cose-issues/ https://github.com/cose-wg/cose-issues/ Basically, it’s a contract-of-adhesion kind of thing, where if you contribute you’re agreeing to IPR associated with it, without signing anything. Now if only we had consent receipts or something that could generate from this transaction... — Justin

...

On Sep 2, 2015, at 12:07 AM, Eve Maler wrote:

Oh sorry, you did address closing the repo. I think we can only execute on “Only primary editors should have write access to the repository and should be allowed to make changes directly to it” if we do that, and it will have the same effect on the issues, iirc.

Eve

...
On 1 Sep 2015, at 9:05 PM, Eve Maler mailto:eve@xmlgrrl.com> wrote:

This makes sense to me. I think James brought up using branches for everything just because he’s involved in insanely large projects. :-)

We didn’t actually conclude our discussion of whether to “close” the repo in order to look after IP hygiene, but it sort of relates to this topic. (Though pull requests from random non-participant strangers can always be put aside; it’s more the issue discussions that we were asking about).

Eve

...
On 1 Sep 2015, at 7:24 PM, Justin Richer mailto:jricher@mit.edu> wrote:

The overhead associated with fully distributed development when there is a clear core team is not worth the headaches it can cause, especially since nobody that I can see would be taking the job of patch integrator to manage all the pull requests. Having an editor create a pull request and then merge it themselves into the main repository is just a waste of that editor’s time.

Only primary editors should have write access to the repository and should be allowed to make changes directly to it. Things that are WG consensus should go on “master” (or the appropriate version-tracked major branch), proposed solutions and text by the primary editors should go on branches in the main repository and brought to the group for feedback.

Non-editors (like myself) can fork the repository, branch, and create either pull requests or simply reference commits and issues from there.

— Justin

...
On Sep 1, 2015, at 10:14 PM, Maciej Machulak mailto:maciej.machulak@gmail.com> wrote:

Hi all,

I refer to my earlier email - any comments? :-) Thanks!

Maciej

On 27 August 2015 at 22:39, Maciej Machulak mailto:maciej.machulak@gmail.com> wrote: Hi,

It was discussed today how the current process of spec editing looks like on GitHub (currently the spec is here: https://github.com/KantaraInitiative/wg-uma https://github.com/KantaraInitiative/wg-uma). All the changes are done on this repository, some via branches and some directly to the master branch. It was suggested that maybe we could use distributed repos (each editor would have a fork of the repo) and changes to the main repo would be done via pull requests.

While I agree that using pull requests is best practice, I think we could do without this for UMA spec editing. The current setup which we have is pretty low overhead and sufficient for our needs (we could probably improve on using branches but that's also not something we have to strictly stick to).

However, I'd like to hear the opinion of others. Let me know so that we can act accordingly.

Maciej

-- Maciej Machulak email: maciej.machulak@gmail.com mailto:maciej.machulak@gmail.com mobile: +44 7999 606 767 tel:%2B44%207999%20606%20767 (UK) mobile: +48 602 45 31 66 (PL)

-- Maciej Machulak email: maciej.machulak@gmail.com mailto:maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com mailto:xmlgrrl@gmail.com

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com mailto:xmlgrrl@gmail.com

Eve Maler

2:40 p.m.

New subject: Handling spec writing process @ GitHub [+legal]

This is great input. Dazza also aligned with transparency generically in his previous note; now that we’ve brought up the IP regime specifically, it would be good to see if the DoLs (disputation of lawyers) as a whole have additional thoughts. I’ve flagged the topic in the subject line. We do have a README with an IP health warning now, seen here… https://github.com/KantaraInitiative/wg-uma Perhaps you and Maciej and I can take this offline, but I see that COSE decided to have separate repositories in order to get …/cose-issues. Since the wg-uma repository currently sits under …/KantaraInitiative, I wonder what’s a good way to put the warning in front of people when they hit the issues landing page. Eve

...

On 2 Sep 2015, at 7:18 AM, Justin Richer wrote:

I would strongly recommend *against* closing the issue tracker. If you had done so before, I wouldn’t have been able to submit *any* of the issues that I had. Don’t stand in the way of well meaning people who want to make contributions. :)

I’m not a lawyer, but I’ve dealt with this in other venues. In software, generally, reported issues in a public tracker like this are considered contributions, and not all contributions covered by whatever licensing the codebase has. And since the issues do not directly affect the codebase (even pull requests) but have to go through a core contributor’s hands, there’s a gating system built in. You can also put a notice to this effect (like the IETF Note Well or a software project’s LICENSE file) in the main project that the issue tracker is attached to. We’re doing something like this with COSE:

https://github.com/cose-wg/cose-issues/ https://github.com/cose-wg/cose-issues/

Basically, it’s a contract-of-adhesion kind of thing, where if you contribute you’re agreeing to IPR associated with it, without signing anything. Now if only we had consent receipts or something that could generate from this transaction...

— Justin

...
On Sep 2, 2015, at 12:07 AM, Eve Maler mailto:eve@xmlgrrl.com> wrote:

Oh sorry, you did address closing the repo. I think we can only execute on “Only primary editors should have write access to the repository and should be allowed to make changes directly to it” if we do that, and it will have the same effect on the issues, iirc.

Eve

...
On 1 Sep 2015, at 9:05 PM, Eve Maler mailto:eve@xmlgrrl.com> wrote:

This makes sense to me. I think James brought up using branches for everything just because he’s involved in insanely large projects. :-)

We didn’t actually conclude our discussion of whether to “close” the repo in order to look after IP hygiene, but it sort of relates to this topic. (Though pull requests from random non-participant strangers can always be put aside; it’s more the issue discussions that we were asking about).

Eve

...
On 1 Sep 2015, at 7:24 PM, Justin Richer mailto:jricher@mit.edu> wrote:

The overhead associated with fully distributed development when there is a clear core team is not worth the headaches it can cause, especially since nobody that I can see would be taking the job of patch integrator to manage all the pull requests. Having an editor create a pull request and then merge it themselves into the main repository is just a waste of that editor’s time.

Only primary editors should have write access to the repository and should be allowed to make changes directly to it. Things that are WG consensus should go on “master” (or the appropriate version-tracked major branch), proposed solutions and text by the primary editors should go on branches in the main repository and brought to the group for feedback.

Non-editors (like myself) can fork the repository, branch, and create either pull requests or simply reference commits and issues from there.

— Justin

...
On Sep 1, 2015, at 10:14 PM, Maciej Machulak mailto:maciej.machulak@gmail.com> wrote:

Hi all,

I refer to my earlier email - any comments? :-) Thanks!

Maciej

On 27 August 2015 at 22:39, Maciej Machulak mailto:maciej.machulak@gmail.com> wrote: Hi,

It was discussed today how the current process of spec editing looks like on GitHub (currently the spec is here: https://github.com/KantaraInitiative/wg-uma https://github.com/KantaraInitiative/wg-uma). All the changes are done on this repository, some via branches and some directly to the master branch. It was suggested that maybe we could use distributed repos (each editor would have a fork of the repo) and changes to the main repo would be done via pull requests.

While I agree that using pull requests is best practice, I think we could do without this for UMA spec editing. The current setup which we have is pretty low overhead and sufficient for our needs (we could probably improve on using branches but that's also not something we have to strictly stick to).

However, I'd like to hear the opinion of others. Let me know so that we can act accordingly.

Maciej

-- Maciej Machulak email: maciej.machulak@gmail.com mailto:maciej.machulak@gmail.com mobile: +44 7999 606 767 tel:%2B44%207999%20606%20767 (UK) mobile: +48 602 45 31 66 (PL)

-- Maciej Machulak email: maciej.machulak@gmail.com mailto:maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com mailto:xmlgrrl@gmail.com

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com mailto:xmlgrrl@gmail.com

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Dazza Greenwood

2:47 p.m.

New subject: Handling spec writing process @ GitHub [+legal]

What Justin said should reasonably suffice but to add more IP protection GitHub can produce an automatic notice to all issue submitters. We just need a How to Contribute to the Repo file to trigger this feature. I'll post a link in a few minutes to show how and provide example organizations that do this practice. | Sent from my iPhone | Please Forgive Typos _________________ | Dazza Greenwood, JD | CIVICS.com, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza@CIVICS.com | Biz: http://CIVICS.com | MIT: https://law.MIT.edu | Me: DazzaGreenwood.com | Twitter: @DazzaGreenwood | Google+: google.com/+DazzaGreenwood | LinkedIn: linkedin.com/in/DazzaGreenwood | GitHub: github.com/DazzaGreenwood/Interface

...

On Sep 2, 2015, at 10:40 AM, Eve Maler wrote:

This is great input. Dazza also aligned with transparency generically in his previous note; now that we’ve brought up the IP regime specifically, it would be good to see if the DoLs (disputation of lawyers) as a whole have additional thoughts. I’ve flagged the topic in the subject line.

We do have a README with an IP health warning now, seen here…

https://github.com/KantaraInitiative/wg-uma

Perhaps you and Maciej and I can take this offline, but I see that COSE decided to have separate repositories in order to get …/cose-issues. Since the wg-uma repository currently sits under …/KantaraInitiative, I wonder what’s a good way to put the warning in front of people when they hit the issues landing page.

Eve

...
On 2 Sep 2015, at 7:18 AM, Justin Richer wrote:

I would strongly recommend *against* closing the issue tracker. If you had done so before, I wouldn’t have been able to submit *any* of the issues that I had. Don’t stand in the way of well meaning people who want to make contributions. :)

I’m not a lawyer, but I’ve dealt with this in other venues. In software, generally, reported issues in a public tracker like this are considered contributions, and not all contributions covered by whatever licensing the codebase has. And since the issues do not directly affect the codebase (even pull requests) but have to go through a core contributor’s hands, there’s a gating system built in. You can also put a notice to this effect (like the IETF Note Well or a software project’s LICENSE file) in the main project that the issue tracker is attached to. We’re doing something like this with COSE:

https://github.com/cose-wg/cose-issues/

Basically, it’s a contract-of-adhesion kind of thing, where if you contribute you’re agreeing to IPR associated with it, without signing anything. Now if only we had consent receipts or something that could generate from this transaction...

— Justin

...
On Sep 2, 2015, at 12:07 AM, Eve Maler wrote:

Oh sorry, you did address closing the repo. I think we can only execute on “Only primary editors should have write access to the repository and should be allowed to make changes directly to it” if we do that, and it will have the same effect on the issues, iirc.

Eve

...
On 1 Sep 2015, at 9:05 PM, Eve Maler wrote:

This makes sense to me. I think James brought up using branches for everything just because he’s involved in insanely large projects. :-)

We didn’t actually conclude our discussion of whether to “close” the repo in order to look after IP hygiene, but it sort of relates to this topic. (Though pull requests from random non-participant strangers can always be put aside; it’s more the issue discussions that we were asking about).

Eve

...
On 1 Sep 2015, at 7:24 PM, Justin Richer wrote:

The overhead associated with fully distributed development when there is a clear core team is not worth the headaches it can cause, especially since nobody that I can see would be taking the job of patch integrator to manage all the pull requests. Having an editor create a pull request and then merge it themselves into the main repository is just a waste of that editor’s time.

Only primary editors should have write access to the repository and should be allowed to make changes directly to it. Things that are WG consensus should go on “master” (or the appropriate version-tracked major branch), proposed solutions and text by the primary editors should go on branches in the main repository and brought to the group for feedback.

Non-editors (like myself) can fork the repository, branch, and create either pull requests or simply reference commits and issues from there.

— Justin

...
On Sep 1, 2015, at 10:14 PM, Maciej Machulak wrote:

Hi all,

I refer to my earlier email - any comments? :-) Thanks!

Maciej

> On 27 August 2015 at 22:39, Maciej Machulak wrote: > Hi, > > It was discussed today how the current process of spec editing looks like on GitHub (currently the spec is here: https://github.com/KantaraInitiative/wg-uma). All the changes are done on this repository, some via branches and some directly to the master branch. It was suggested that maybe we could use distributed repos (each editor would have a fork of the repo) and changes to the main repo would be done via pull requests. > > While I agree that using pull requests is best practice, I think we could do without this for UMA spec editing. The current setup which we have is pretty low overhead and sufficient for our needs (we could probably improve on using branches but that's also not something we have to strictly stick to). > > However, I'd like to hear the opinion of others. Let me know so that we can act accordingly. > > Maciej > > -- > Maciej Machulak > email: maciej.machulak@gmail.com > mobile: +44 7999 606 767 (UK) > mobile: +48 602 45 31 66 (PL)

-- Maciej Machulak email: maciej.machulak@gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL) _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

3302

Age (days ago)

3308

Last active (days ago)

List overview

Download

8 comments

4 participants

participants (4)

Dazza Greenwood
Eve Maler
Justin Richer
Maciej Machulak

Handling spec writing process @ GitHub

tags

participants (4)