Confirmed users
210
edits
Websites/Plugincheck: Difference between revisions
→Ideas On Improving PluginCheck
Espressive (talk | contribs) |
Espressive (talk | contribs) |
||
| Line 76: | Line 76: | ||
== Plugin Data as an Open Service == | == Plugin Data as an Open Service == | ||
Seeing that there is no inherent private data in the information on plugin release statuses, another idea that was discussed, was to borrow from the process followed to manage information about browser feature support at caniuse.com [https://github.com/fyrd/caniuse]. The basic process is as follows: | |||
1) JSON files for each plugin are stored at: | |||
https://github.com/ossreleasefeed/plugin-status-service/tree/master/data | |||
2) From here, vendors, community members, pretty anyone comfortable with Git/Github/JSON can fork the repo | |||
3) Once there is a new release, a user can simply open up the JSON file for the affected plugin and update or add the details of the release. | |||
4) Once the information has been updated, the user pushes the change to their repo and opens a pull request against the main repo. | |||
5) Trusted users who have been given merge access to the main project repo can then review the PR and merge | |||
6) Once a merge to master has been made, a service such as leeroy can be used to kick off a process that would pull down the latest from Github and then call the following file via Node: | |||
https://github.com/ossreleasefeed/plugin-status-service/blob/master/db/create_plugincheck.js | |||
7) Once that process is complete, a new mongodb instance of the DB will exist and subsequent calls to the service will respond with up to date information. | |||
This project has largely been abandoned as the use of Git/Github/JSON is too prohibitive, and perhaps adds to much complexity. | |||
However there is much more needed in terms of data translation to a DB format at caniuse, plugincheck would actually need very little, if any. | |||