Loomio
Thu 31 Mar 2016

Alternative version control repositories

JR
Jason Ryan Public Seen by 340

Propose that options in addition to Github are mentioned....

Principles guiding the choice of code repository for publicly-funded software:
* repository provides full public access to source code, to promote discovery and re-use
* respository software support government standards for accessibility for a full range of users
* repository software is itself free code, with no proprietary dependencies, so a user can access it without being required to use any proprietary software, either directly or indirectly
* repository software implements all relevant open standards
* respository may be self-hosted by the project or department developing it, or another public organisation, or a gratis public service hosted by an external provider
* projects and the repository they are using should be listed on a regularly-updated list of free code projects used across all-of-government, to increase standardization and reduce unnecessary duplication of effort

JR

Jason Ryan Thu 31 Mar 2016

61(a) using a version control repository like Github; and

Could offer other alternatives for balance (eg, Bitbucket) or, preferrably, suggest FOSS options like Gitlab which could be hosted in the .govt.nz domain, or they could use the NZOSS one until they stand up their own...

DL

Dave Lane Thu 31 Mar 2016

That sounds like a great idea :)

CF

Cam Findlay Thu 31 Mar 2016

Perhaps the specifics on exactly what tech to use could be made available outside the policy (after all NZGOAL is all about licensing)? I note that the US Fed Govt are going through a public consultation on their FOSS policy and intend to have practical guidance and policy separate and referencing each other. Technology will change over time and the principles in the policy ideally can allow for this to have some longevity.

JR

Jason Ryan Thu 31 Mar 2016

Sure: I'm mostly against an ad for Github in a government policy document...

DL

Dave Lane Sun 3 Apr 2016

For the record, we'd be happy to have people use the NZOSS gitlab instance on https://git.nzoss.org.nz

CF

Cam Findlay Sun 3 Apr 2016

My thoughts here are that what we are really asking for is that code release occurs in a publicly open repository without imposing any particular technologies or locations.

Licensed code on a close repo doesn't promote discovery and reuse. That is a core principle of NZGOAL generally.

As mentioned, a separate set of practical guidance (like has been done with the NZGOAL guidance notes and webtoolkit) could start to suggest these things at a more practical level? (Perhaps this could actually be crowd-sourced from practitioners in this space or stewarded by a Govt Web Community of Practice). Just some thoughts.

As NZGOAL is primarily about licensing and has principles attached to it such as the Open Access principle, it's the right place to state that public access is preferable and not what or where that is.

In saying that, really awesome that NZOSS has an open repo space :thumbsup:

RS

Roy Storey Sun 3 Apr 2016

Hi,

I agree with @camfindlay1 and @jasonryan about the wording and intention of policy and creating an advertisement for GitHub.

Implementors should be free to choose their open repository and its location and have as much control over it as they are willing to furnish and maintain.

BTW they are after us... https://jobs.github.com/positions/bea0d4a0-cb6e-11e5-9a96-a6303511a4e4

CF

Cam Findlay Mon 4 Apr 2016

@roystorey interesting link, let's however keep discussions on topic :thumbsup:

CF

Cam Findlay started a proposal Mon 4 Apr 2016

Code release should occur in a publicly open repository without imposing any particular technologies or locations. Closed Tue 12 Apr 2016

Outcome
by Cam Findlay Wed 26 Apr 2017

Reasonable agreement here that we should keep specific technologies outside the NZGOAL_SE and focus on principles that lead to selection of a suitable release space (however only 42% voted can this be considered "passed"?). There are some further spin off suggestions (summarised at top of thread). We may run follow up polls on each of these items (or split off into own thread for longer form discussion).

Agreement means that you'd like to see the policy wording changed to indicate that the desired behaviour here is release of code in an open and public digital space. This does not include what technology platform to use, nor where this is located online (this would be up to the agency to decide though there might be guidance given outside the NZGOAL-SE).

Agree - 10
Abstain - 10
Disagree - 10
Block - 10
10 people have voted (25%)
CF

Cam Findlay
Agree
Mon 4 Apr 2016

For longevity of the policy, this is a good idea.

DL

Dave Lane
Agree
Mon 4 Apr 2016

I think we should agree that FOSS code should be managed using git, but the repository through which it is shared can be selected (or there can be multiple - see git mirror). Perhaps projects need to register their location somewhere centrally...

SB

Sam Bonner
Agree
Tue 5 Apr 2016

JR

Jason Ryan
Agree
Tue 5 Apr 2016

G

Gold
Agree
Thu 7 Apr 2016

BW

Brent Wood
Agree
Sun 10 Apr 2016

EA

Edward Abraham
Agree
Sun 10 Apr 2016

RE

Rob Elshire
Agree
Sun 10 Apr 2016

DS

Danyl Strype
Agree
Mon 11 Apr 2016

I don't think general policy statements should advertise US-based corporations whose website uses a number of proprietary components (ie GITHub). If specific examples are given they should be chosen from among those that use only free code components

TCY

T. Charles Yun
Agree
Mon 11 Apr 2016

RS

Roy Storey Mon 4 Apr 2016

Code release should occur in a publicly open repository without imposing any particular technologies or locations.

@camfindlay1 I wonder if accessibility is constrained. A publically open repository using an obscure technology is not as accessible as one using a commonly available one. Contributions are increased by simplicity - the only citation I have of this is https://www.youtube.com/watch?v=U8GBXvdmHT4&t=47m00s (a few seconds of listening to Matthew is all that is required...) I would be interested in having a better source to cite.

CF

Cam Findlay Mon 4 Apr 2016

@davelane while I love git, suppose something else new and awesome comes out for version control? Other than being specific about licenses (MIT/GPL/whatever is decided upon) which is what NZGOAL is about, my proposal here is about being technology agnostic. However, could I suggest that we proposed code is at least "in version control" which is really the core principle of what we are perhaps asking for here?

"Perhaps projects need to register their location somewhere centrally..." <- all the yes for this and I think that is a bigger discussion perhaps beyond NZGOAL? I note the US Fed govt open source policy are looking to set up such a register for reusable open source things. See https://github.com/WhiteHouse/source-code-policy/blob/gh-pages/pages/Implementation.md

The US proposed policy is framed in a much more aggressive push to mandate new code release (that we haven't tackled, yet, in NZ). NZGOAL might be a solid stepping stone towards this (NZGOAL is focused on solid licensing principles and guidance).

DL

Dave Lane Tue 5 Apr 2016

I'm strongly in favour of ratcheting up from "encourage" to "mandate", especially in terms of compliance with open standards, but also open source for all NZ gov't funded software development.

DL

Dave Lane Tue 5 Apr 2016

I'm also keen to see us stipulate a version control technology that is a) open (no barriers to adoption) and, b) widely used. At present, we're in the lucky situation that the most widely used is also open (as are next couple most widely used, e.g. mercurial and bazaar)... In future, I'd be keen to adopt the most widely used and also open technology, if/when something supersedes git.

RS

Roy Storey Tue 5 Apr 2016

What is the lead time on this new technology? Is the policy able to cope with editing this frequently? If not, slight ambiguity might be warranted to address longevity of the policy.

Can this be solved with Best Practice based on the policy? Best Practice documents may be more maleable than a policy that specifies the why / philosophy or chosing open source/version control/GPL etc...

CF

Cam Findlay Wed 6 Apr 2016

@roystorey can we crowd-source these practice documents from practitioners on the ground or through communities of practice perhaps?

RS

Roy Storey Wed 6 Apr 2016

@camfindlay1 I'd like to say yes. Many government funded organisations are on GitHub and could contribute - if we are talking source control specifically, but this would extend to other informatics areas also.

CF

Cam Findlay Sun 10 Apr 2016

@davelane would it be advantageous to stipulate in NZGOAL-SE that the version control technology (and software clients to access) conform to an open standard and/or be available as FOSS itself? Git, for example fits that pattern (along with others).

The open access principle might not work if a release is made, on a public version control system that requires some proprietary software client to access/track any contributions or modifications.

Pretty much, I don't mind if it's released on git, subversion, mercurial etc, as long as the tool is open and freely available for me to interact with the released FOSS software under NZGOAL-SE. :thumbsup: I think that's what is important.

DL

Dave Lane Sun 10 Apr 2016

I agree that I'm happy as long as the version control system is open source itself.

EA

Edward Abraham Sun 10 Apr 2016

I agree that it is great to separate mention of GitHub out from the policy. But there needs to be a how to guide, giving examples of how to satisfy the policy. Releasing software on Github is a common way for people to maintain an open source project. This choice (Github/Gitlab/Bitbucket), is about the broader considerations of maintaining the software, rather than the licensing per se.

CF

Cam Findlay Sun 10 Apr 2016

@edwardabraham I started drafting something along these lines last year as practical guidance for Common Web Platform.

See https://github.com/camfindlay/opensource-nzgovt/tree/master/a_guide_to_better_code_sharing_on_cwp

Perhaps this could be built on into a more generalised set of FOSS guidance. Happy for it to be reused and crafted into some sort of help guide outside of NZGOAL-SE :+1:

RE

Rob Elshire Sun 10 Apr 2016

I agree with publicly open repositories. There should not be an imposition of non-FOSS tools either. Then there is the issue of discoverability. I think that is being discussed in a different thread.

DS

Danyl Strype Mon 11 Apr 2016

As others have said, what the NZGOAL wording needs to do is tease out and make visible the principles that lead us to recommend GIT, and to endorse or not endorse specific platforms (eg GITHub/ GITLab). I'll attempt to sum up the principles that have fallen out of this discussion in the context box (top of the page).

CF

Cam Findlay Mon 11 Apr 2016

Thanks for the summary @strypey :clap:

DC

Don Christie Tue 12 Apr 2016

Hi, being independent of the likes of github and onshore is important for the initial releases. Others can mirror of they like.

Remember, there are very good reasons no-one uses sourceforge any more.