Playground Management

[dkebler]

This will be a permanent discussion topic as regards how we want to organize and manage the playground's content.

All are welcome to make suggestions or proposals and submit related PRs

[dkebler]

Not that at this time we have much of any content but on the assumption we will I propose we have (at least at this time) five main subdirectories with a corresponding category in Discussions.

• Developer Tools - any developer tools that help us to do tasmota berry coding.
• Modules - ready to go modules that can be downloaded and incorporated into an app or driver
  we might want subdirectories therein to help organize them if this part of the repository gets large
  I see this is like a "registry of node modules" but for berry.
• Apps - Full blown, complete, ready to go applications
• Drivers - fully functional driver
• Tutorials and Code Blocks - How To's each focusing on a single coding challenge

The whole thing should be driven by a readme file in each subdirectory. So for example any PR would include a folder of what you are contributing put in the right main subfolder above and your folder would have a readme file explaining the contents of your folder and how to use it.

(I suppose we could use the repo wiki but maybe this is just cleaner and doesn't add another thing to maintain and is supported by PRs)

As to Discussions, we should scrub the current discussion categories and replace with these above plus a management category and a general help category. (@Jason2866 I have access to manage discussion posts but not to manage discussion categories, is it possible to add that to my permissions, nevermind see now I do have access to do this)

I'll wait several days to get some input on my proposal above and then publish a "skeleton"

[dkebler]

Given this folder structure participants can first propose new content via a discussion topic where others can comment and give input. If it seems worthy then they can put together a PR (a folder of their contribution) and it can be vetted and merged. Some discussions won't warrant a PR but a link could be made in the readme of that subdirectory to the discussion. (e.g. some good tip about developers tools in a discussion could have a link to it in the developer tools subdirectory readme).

Note, some contributions may be nothing more than a link to an outside repo with their contribution although I personally don't want to see this repo as just another "awesome" list.

[dkebler]

see #6

[darrylb123]

I submitted a pull request, which was accepted. I suspect most of my future submissions will fit under the Tutorials and Code Blocks area. I'd like to see some linkage between the various libraries and the code blocks. That said, a working example will often contain several libraries but I think the main purpose of the example should determine it's location. Eg, mqtt examples will contain some json or string functions. these can be handy for context anyway.
Feel free to build your structure and move the files to the relevant place. I have been working on more snippets of areas of Berry i have used.

[btsimonh]

A thought Ref License...
I love MIT and Apache2 licenses... but the MIT asks "The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software."

Since we (normally) wish to minimise occupied file space in Tas, maybe we could note that in our case 'substantial' does not include using/modifying modules, examples, etc. in the Tas filesystem environment?

[dkebler]

yes that part is not necessary. Maybe also we should be clear that any contribution to this repo will then fall under the license of the repo and that any contribution should include any code with a more restrictive license.

[btsimonh]

In my upcoming modules contribution readmes (e.g. this one ), I've included a couple of things that may be helpful in general in contributions.

One is the 'Features used' - just a list of what the contributor felt were the interesting/important Tas/Berry features illustrated by the example/module/contribution.

The other is a comment on Stability. i.e. whether people should think of it as a complete thing, something to play with, or just example code to read; and if the code is expected to be updated frequently or infrequently.

I feel a template contribution readme coming on....?

[dkebler]

@btsimonh , Also if want to make changes to the rest of the repo in api contribution PR or another one go for it (e.g the wiki link). Further if you feel inclined to be more involved in the management then I'd be good with giving you publish rights.