Comments (20)
I'm interested in helping with some of this. If the website and API are moved, it seems like it would make sense to split the website and API into separate initiatives since the website can be an API consumer like any other project. (I'm still catching up on the linked issues, so forgive me if I'm restating something that's already been discussed or isn't wanted)
While I'm navigating through the issues, what are your thoughts about which things need to be done first?
from licenses.
Alright with me if this repo becomes dataset-only.
Assuming some people are using the API (which is really just static json) what to do about them? Apparently they exist #37
from licenses.
For people already using we will aim to do redirect and provide backwards compatibility even if API moves to opendefinition.org site
from licenses.
we will aim to do redirect and provide backwards compatibility
makes sense. I'm going to schedule some time to get familiarized with the project(s) later this week.
In the meantime, just to make sure we're thinking the same thing, how does the following sound to you:
- simplify/refactor
ofkn/licenses
repo:- dataset-only (including necessary scripts for generating dataset)
- refactor build/deployment scripts to javascript/node.js
- jettison the website code
- proper unit tests
- move API code to separate project. Since this is a pretty simple script, IMHO this should be maintained separately from the website code to decrease barriers for contributing to each repo, and keep issues more focused. e.g. devs that want to do a patch for the API code won't need to worry about messing with HTML/CSS and vice-versa
- update the website, which would be almost entirely design-oriented if the API code is moved out.
All of this should be done on branches in the respective repos so that once the work is complete we can deploy everything simultaneously with as little impact to end-uses as possible. this all seems pretty easy but I might be missing some important details.
sound close/reasonable?
from licenses.
We won't need unit tests if data only. In terms of API and website I think we either want to move to opendefinition repo or still keep here but perhaps just in the gh-pages branch.
Generally sounds very good. Can you also sync in #44
from licenses.
@jonschlinkert let's move forward here as per your suggestions. My sense is that we are going to strip this repo down to being just the data and data package - we might just include a script for generating json versions of the data but i'm not sure ... We then have two options
- we fork this repo to e.g. "licenses-api". this could still run the licenses.opendefinition.org site
- or we merge into the opendefinition repo and site http://opendefinition.org/ (see description of this issue above)
from licenses.
@jonschlinkert do you have capacity to contribute here? It would be great to move this forward and complete :-)
from licenses.
I've been following along for a while, and may be able to help out with the dataset-only repo. I'm a data nerd and open source lawyer, know Python, and have been dabbling in NodeJS/npm recently.
Seems like Gulp might be a good fit for retooling the build scripts, although I admit I haven't 100% wrapped my brain around it it. See, for example, the json-combine plugin.
from licenses.
@rgrp sorry I've been focused on raising funding quite a bit recently. perhaps @anseljh and I can collaborate in some capacity.
@anseljh if you want to take the ball and run with it, I'd be happy to help review or contribute to whatever you come up with. I have experience with node.js and gulp, so I can at least try to answer any questions you might have
from licenses.
@jonschlinkert Sounds good. I will start tinkering and keep you all posted. Shall we break this into a handful of more discrete issues?
from licenses.
@anseljh sounds good. Do you want to take an initial stab based on your understanding so far and then we refine?
from licenses.
@anseljh how's it going? Want to get clear on the plan?
from licenses.
Let the data be the API.
from licenses.
Hello! @rgrp I did get started, but haven't had time to continue yet. Hopefully over the weekend I will have some time.
If you want to take a peek, my work in progress is in the dataset-only
branch on my fork: https://github.com/anseljh/licenses/tree/dataset-only
from licenses.
@anseljh that looks like a great start! @doowb and I are the maintainers of gulp-convert if you have any questions with the conversions
from licenses.
@anseljh great - would it be wroth you quickly listing out here in a comment your "plan of attack" and your planned endpoint - that will make sure we are all on the same page :-)
from licenses.
Only for a test, but an actual consumer https://github.com/github/choosealicense.com/blob/c8012557a4b5e9efd560e6d58fcbef50f29a1d46/spec/spec_helper.rb#L101
from licenses.
Given that there is now an up to date dataset via #57, what should be the next step? I was thinking that changes are maintained via the csv and the json generated when the csv changes. Thoughts?
from licenses.
@Stephen-Gates totally agree that csv should be central and then json is generated. I think pushing this to datahub.io (as that will autogenerate json - though we may also want to make sure we don't break any links here ...).
from licenses.
Here's my suggestion to progress this issue
from licenses.
Related Issues (20)
- Against DRM's license page broken HOT 1
- License Update suggestions HOT 6
- Free/Open Licenses Data Package HOT 22
- The family field, and the similar licenses HOT 4
- Wikidata IDs HOT 6
- Add test to check licenses.csv against datapackage.json HOT 7
- add french open licence HOT 3
- add a description for each field in the datapackage.json schema
- Repository labels HOT 1
- some license identifiers conflict with SPDX HOT 1
- Add French open license inside ckan group HOT 2
- LO-FR-2.0: is_generic field is of type string
- DNS misconfigured for licenses.opendefinition.org? HOT 2
- licenses.csv is not generated from json datafiles HOT 5
- Add Eclipse License version 2.0 HOT 4
- Plain language summary link for Open Database License (ODbL) v1.0 is broken HOT 3
- spam
- :pray: Missing licences > CC BY-ND 4.0, CC BY-NC-SA 4.0,CC BY-NC-ND 4.0 HOT 18
- :link: Feature Request > Add links to licence logos :camera: HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from licenses.