Create a meta .github repo for the Silverstripe organisation #1
Comments
|
For INITIAL PEER REVIEW - this is my proposed approach - please let me know if you agree / disagree / would change bits Methods of updating files in repos
Because we need to do 2. to meet the AC's of this card, I think it makes sense to expand the scope of this card a bit to do more stuff "while we're at it" Meta files to update in all reposDo update / overwrite (these will also be added as templates in .github)
Add if they don't already exist (these will also be added as templates in .github)
Remove if they exist
Do not update
|
|
You haven't mentioned an organisation-level README in your breakdown above. Are you implying by omission that we shouldn't have one, or do you consider this a step to be done after the above, or....?
[the github docs about default "health" files] mentions what specific files are supported. The following are not included in that list, but you've included above as "will also be added as templates in .github":
Did you mean something else by "template"? If so, please define that or point to the relevant documentation that defines it. |
|
Re org level readme - yes sorry, we'd need to add useful stuff in there, presumably it's would be a composite of CONTRIBUTING.md and other meta files That's really cool about the default health files I didn't realise that was a thing (didn't realise you had it linked in the description). That's a nice mechanism Given that SECURITY.md is an official health file perhaps it does make sense to put the link to security@silverstripe.org in there with instructions By "template" my (bad) assumption was that you could define "template" for these files .github that get copied to new repos, rather than ?symlinked? in if there isn't an existing file (presumably not copied). So given that, "templates" aren't a thing We will need to scan all the modules for non BSD-3 licenses and it seems like the existing tool I linked to before would be useful for this. Given that tool was designed specifically to standardise specific files (including deleting files), the amount of scope creep added here is actually pretty low so I think it's worthwhile doing e.g. ensuring .editorconfig is standardised, deleting changelog.md, etc |
|
Fair. Yup, sounds like that's a good plan of attack, then. |
|
I used github advanced search to look at all the repos with existing licences: 0bsd - 4 results
bsd-2-clause - 2 results
bsd-3-clause - 134 results
mit - 2 results
No other license types found MIT is closest to BSD-2 BSD licenses - https://fossa.com/blog/open-source-software-licenses-101-bsd-3-clause-license/ BSD-3 - 3rd clause not in BSD-2 is (also known as the “non-endorsement clause”). This is the clause that prohibits users from using the name of the project to promote their derivative work(s) BSD-0 is basically a 'do whatever you want license, including deleting the license' Given that the non BSD-3 licenses are all more permissive, I see little reason to change them if we're not concerned about consistency. Note developer-docs uses https://creativecommons.org/licenses/by/3.0/nz/ - this wasn't picked up by github advanced search - this type of license is very permissive like the other licenses we use |
|
@maxime-rainville I ran a quick and dirty script to find out what repos on silverstripe account (including unsupported) have no license UPDATE: My original script was incomplete was didn't query every repo. I've updated the script, and gotten it to filter out any forks and archived repos - I'll do PR's for all the of the following to add BSD-3 LICENSE files Let me know if there are any where we do NOT want BSD-3 added to it |
|
At first glance, I'm fine with BSD-3 on everything. If the repo is a fork from something else, maybe validate what the original license was. The worst case scenario is if we forked something that was under something like GNU GPLv3 license, because we would be violating that license by republishing the thing under BSD-3. If we are confident that a module was created by an employee of Silverstripe Ltd on Silverstripe Ltd time, I don't necessarily have beef with removing the name of the original author because Silverstripe would own the copyright anyway. Also, I think it's legally allowed to publish a module under multiple licenses. For example, you could publish something under GPLv3 and if someone wants to be able to make changes without having to share them back, they can ask you for a commercial license (MySQL made a boat load of money that way back in the day). So changing the license after the fact, should be kosher in most cases as long as we own the original right on the thing. |
|
This a list of files with existing 'health files' - meaning a contributing, support, security or code-of-conduct style file - again used a script Before deleting things, we need to merge the .github PR and try deleting files in a single repo to validate that the .github health files are "passed through" |
You can just create a fork - forks are free. What about them makes them seem like having a license isn't appropriate? I don't feel strongly either way, so feel free to just leave your opinion and not add licenses if that's what you choose. It just feels a little arbitrary right now given some of the repos (some very long abandoned) that did get licenses added. |
|
PRs merged. Reassigning to @emteknetnz for next steps (and to respond to the above comment) |
|
Looks like we totally misunderstood what the health files actually do This do not "pass through" to individual repos - instead what they do is show up as links when you open a new issue or pull request, e.g. |
|
I've spun off the 'update all the files' into a new issue - #70 as it's greatly increased the scope of the original intention of this issue I'll close this issue |
Currently each repository has its own meta files such as "CONTRIBUTING", "SECURITY" etc which are (or should be) identical - or those may be missing entirely. There's no standard or any process for updating them. Ideally those should be standard and all point to the relevant docs.
.githubrepository allows us to have default meta files.Acceptance Criteria
.githubrepository existsPRs
The following don't have creative-commoners forks, though don't really seem appropriate to even have LICENSE files in them
The text was updated successfully, but these errors were encountered: