RFC : Lazy Submission to OpenHardware.io using GitHub

[soif]

Here is a proposal (RFC) to encourage developers to publish MySensors projects on Github, and get their projects published/updated on OpenHardware.io.

IMHO, developers are lazy, and tracking / gathering project information from the forums, or asking developpers to submit on OpenHardware.io, is also a time consuming process for OH.io maintainers.

What if developpers would just have to follow a very basic file structure, when publishing their projects on GitHub and then to just have to submit their repo URL to MySensors, to get their project AUTOMAGICALLY recorded/updated at OpenHardware.io.

From a developper point of view :

• developers love GitHub but hate filling forms or making documentations
• most developers are LAZY (right?) and just asking them to follow easy conventions when publishing on GH is certainly not that hard, if clearly advertised on mysensors.org or OH.io.
• just pushing new commits to GH, is really more funny/natural , than taking the time to go to OH.io, and submit modifications, new images, new code, etc...
• others developpers could contribute to each others project using GH pull-requests, submitting issues, adding pictures, etc...

From OpenHardware.io mainteners point of view :

• the more way to submit projects, the more projects to get published
• updates could be fully automated (developer push to GH, then OH.io can just automatically fetch new infos)
• It don't prevent non-GH users to use the regular OH.io submission form if they wish
• GH users would be more able/naturally prompted to contribute to each other projects
• Don't re-invent the wheel for developpers interaction/collaboration, by just interfacing with GH
• easy to implement

So to make this more comprehensible, I've pushed a proposal of a Mysensors Template Project at:
https://github.com/soif/mysensors_template

and a demo showing how this could be easily parsed at :
https://jsfiddle.net/soif/ek5j7pao/

Obviously this is just a draft, and standards should be defined/fixed by OH.io maintainers...

Sounds interesting for you developpers?
And for you OH.io maintainers?

HTH

[hek]

Sounds interesting!

Especially if people could name their projects with a prefix like mysensors-* or openhardware-*. Then I probably could locate them automatically on github and import them.

The current GitHub "crawler" on openhardware.io automatically finds:

• Design files (Eagle, KIcad) and gerbers.
• Images (png, gif, jpeg). It even parses README.md for external images and downloads them.
• Code- The most common code file extensions.
• Treats the first found excel, cvs file as a BOM
• /README.md can be sucked up as description automatically.

I've prepared most of the work to do a daily scan for updates from the registered project github repos also. It will only update projects where the SHA has changed since the last scan.

The only thing that is a bit problematic today is if people keep multiple projects in one repository. I have no way of doing automatic separation of them so the result will not be so good.

Really like the idea of having/supporting a mysensors.json/openhardware.json Makes life much easier!

[soif]

I'm very happy that you've liked the concept.

Asking developpers to prefix their repos name with 'mysensors-' does add some "wild" search abilities, but it'd still not fully let you properly index projects.

But a REALLY SIMPLE (this IS the key) JSON file + file structure, is easy to implement for developpers, and would make your life crawling their repo, really safer while letting developpers being focused on what they do best (coding), whithout asking them to follow (boring for them) procedures to publish their projects on OH.io.

They (or anybody else) would just have to submit the repo URL, and your robots could SAFELY do the rest.

I do believe that standardization is the shortest way and the key to success for both parties (developpers and maintainers), assuming the standard is really simple to implement. Look how fast composer has become the absolute leader in php libraries packages in just a few months, while other (complicated) solutions have pre-existed since years (ie PEAR).

BTW, in my Template JSON definition, I've filled a 'type' (=project) field, intended to define that the repo is a 'project'. But there could be some others useful types, ie:

• library : for arduino libraries relying on Mysensors
• devtool : for applications like MYSController or NRF24_Sniffer
• misc : IE, I've made an Excel file which translate Gateway or Debug messages to human readable messages : where sould I share this back to the community, except in an obscure forum post at MySensors website?
• etc....

You could also, like in Composer, include libraries dependencies imanagement.

Food for the mind

[soif]

anyone else comments?

[soif]

I've just posted a PHP class for Mysensors. More at :
http://forum.mysensors.org/topic/3102/mysensors-php-api-class-command-line-script
https://github.com/soif/MySensors_Php_API

It currently uses the .json file / file structure Standard proposed above.

Enjoy

[hek]

I haven't forgotten this. Just that I've been playing with a websocket gateway the last couple of nights.

I would like to get a bit further exploring a possibility of creating a sensor cloud playground for the community before I return fixing some loose ends on openhardware.io. Just wish I had more hours for MySensors things.

[soif]

@hek just keep up your AMAZING work on MySensors.
Maybe my command line tool may help you to save some time typing in a telnet console.

We're all wishing to get a few more hours per days

[soif]

Did you still consider adding the mysensors.json file or some sort of file stucture standardization in the Github repos?

FYI I have some MySensors projects using the previous proposed standard :

https://github.com/soif/MySensors_ChristmasTree
https://github.com/soif/MySensors_MonitorsRelay
https://github.com/soif/MySensors_HSV_RGB_IR

and still
https://github.com/soif/MySensors_Template
https://github.com/soif/MySensors_Php_API

But it you finally don't mind (I guess) to use the proposed file structure or json files, I would like to make some clean-up in my repos...

[hek]

Keep it in, won't disturb anyone.

[soif]

Except adding a little bit more work to maintain changes in version, date, description, adding photos, etc... So as it is not used I this time , I will remove it.

Anyway, It would be really easy to revert the (clean-up) commit, whenever you'd decide to use this suggested (or another similar) standard.