Originally, I put the existing ToD design pattern example under Community and planned to put the rest of them in there too. This was eventually moved to a separate directory for Script Examples, in a special directory to highlight the design pattern examples (/Script Examples/Design Patterns/). This is currently where any new ones should go. I don’t see why we couldn’t have two ToD examples, but we can figure out the best way to handle it when you submit a PR for yours.
Good timing for your post though, since last night I was experimenting with moving the Mode (ToD) example back under Community in preparation for my Area Trigger/Action post, which uses it. It’s easier and more consistent to install from Community, and the docs can still be available under Script Examples. I’m still thinking through this. If it’s a working example, I don’t see why it wouldn’t be under Community. The Community namespace is just going to get awfully crowded if there are 10 different versions of the same thing, which was one of my initial concerns that I’d voiced about the directory structure. We’re probably good for now, but as more things get submitted, we’ll need to come up with a better solution. The ultimate goal being an ExtensionService for automation (script engines, scripts, libraries, rules and rule templates).
Everything under Community should be a script or a package. For most of these packages, the code will only go into community.my_package.__init__.py. For example, autoremote.
That is incorrect. The personal.__init__.py module is intended to be editable. I have a commit to submit merged using the proposed solution from [personal.__init__] Upgrades will overwrite this file · Issue #218 · openhab-scripters/openhab-helper-libraries · GitHub to prevent it from being overwritten during upgrades.