💡 Read when creating an issue or PR ⬇️

[jokob-sk]

Contributing to this project

The issue tracker is the preferred channel for bug reports, features requests and submitting pull requests.

🐛 Submitting an issue or bug

Before submitting a new issue please spend a couple of minutes on research:

• Check 🛑 Common issues
• Check 💡 Closed issues if a similar issue was solved in the past.

⚠ Please follow the pre-defined issue template to resolve your issue faster.

Please read: https://github.com/jokob-sk/Pi.Alert/tree/main/docs#-submitting-an-issue-or-bug

🙏 Feature requests

Please be as detailed as possible with workarounds you considered and why a native feature is the better way. This gives me better context and will make it more likely to be implemented. Ideally a feature request should be in the format "I want to be able to do XYZ so that ZYX. I considered these approaches XYZ".

Please read: https://github.com/jokob-sk/Pi.Alert/tree/main/docs#-feature-requests

👨‍💻 Development priorities

Highest to lowest:

• Fixing core functionality bugs not solvable with workarounds
• New core functionality unlocking other opportunities (e.g.: plugins)
• Refactoring enabling faster implementation of future functionality
• UI improvements

Design philosophy: Focus on core functionality and leverage existing apps and tools to make NetAlertX integratable into other workflows.

Examples:

1. Supporting apprise makes more sense than implementing multiple individual notification gateways
2. Implementing regular expressions support across settings for validation makes more sense than validating one setting with a specific expression. 

Feel free to submit PRs if interested. try to keep the PRs small/on topic so they are easier to review and approve.

Please read: https://github.com/jokob-sk/Pi.Alert/tree/main/docs#-feature-requests

➕ Pull-requests (PRs)

If you submit a PR please:

1. Check that your changes are backward compatible with existing installations and with a blank setup.
2. Existing features should always be preserved.
3. Keep the PR small, on-topic and don't change code that is not necessary for the PR to work
4. New features code should ideally be re-usable for different purposes, not be for a very narrow use-case.
5. New functionality should ideally be implemented via the Plugins system, if possible.

Suggested test cases:

• Blank setup with no DB or config
• Existing DB / config
• Sending a notification (e. g. Delete a device and wait for a scan to run) and testing all notification gateways, especially:
• Email, Apprise (e.g. via Telegram), webhook (e.g. via Discord), MQTT (e.g. via HomeAssitant)
• Saving settings
• Test a couple of plugins
• Check the Error log for anything unusual

Some additional context:

• Permanent settings/config is stored in the app.conf file

Please go ahead and create an issue with sufficient details if the above didn't help. 😉