Blueprints Etiquette

I have a couple of useful (to me) scripts and automations which I was thinking of converting to blueprints in the hope that others find them useful as well. The first one I was going to start with was a notification automation which alerts me regularly to something which requires my attention, which can be disabled or snoozed (time or location-based) via action buttons on the notification. When looking into the blueprints on the forum I found there are other similar blueprints available already that provide the “nag” functionality, but not the snooze functionality.

I’d be keen to hear the community or core developers’ thoughts on whether it’s better etiquette for me to create a new blueprint for my implementation (which I can then own/maintain), or whether it’s better to reach out to one of the existing blueprint creators to try to incorporate my functionality into their existing blueprints (to try to avoid blueprint-bloat)?

My vote would be the latter first and then if that fails then make one of your own.

We’re already beyond bloat with many different motion blueprints. I’d say post yours up in it’s entirety if you are willing to maintain that into the future.

It’s thoughtful of you to reach out to the community and ask about blueprint etiquette. However, you may have noticed that there are no guidelines or minimum standards for contributions, not even the requirement that the blueprint should work (and quite a few don’t).

Feel free to do what you think is best: collaborate with the author of an existing blueprint or submit your own. If your blueprint works, and contains reasonably efficient code, it will already be better than the norm.

Good luck!

4 Likes