Minimizing Inbox Overload with GitHub Notifications, Gmail, and Outlook Rules

[thabaum]

Hi everyone,

I've noticed that inboxes are getting flooded with commit emails, which can be overwhelming to manage. I'd like to propose a solution to minimize this issue by leveraging GitHub notifications features along with Gmail and Outlook rules. Here are some steps we can take:

• Configure GitHub Notifications: We can customize our GitHub notification settings to receive only the most relevant updates. This will help reduce the number of emails we receive1. For more details, you can refer to the GitHub Docs on Configuring Notifications.

• Set Up Gmail Rules: By creating rules in Gmail, we can automatically move commit emails to specific folders or labels. This way, we can keep our primary inbox clean and organized4. Here's a helpful guide on how to create rules in Gmail: How to Create a Rule in Gmail To Move Emails Automatically.

• Manage Outlook Rules: Similar to Gmail, we can set up rules in Outlook to automatically move commit emails to designated folders. This will help us maintain a tidy inbox and focus on important messages4. You can find more information on managing email messages by using rules in Outlook here: Manage email messages by using rules in Outlook.

By implementing these steps, we can significantly reduce the number of commit emails flooding inboxes and improve our overall productivity. What do you think about this approach? Any additional suggestions or concerns?

Looking forward to your feedback!

[iJungleboy]

@thabaum This is patching a problem that shouldn't exist.

Basically it appears that you're using an unconventional way to make edits and commits which I've never seen before.
So I think we should look at that.

Because we're getting PR notifications, which don't make sense. PRs are meant to submit something you completed, usually just 1 notification.

The normal procedure with fork, work, commit - and only create the PR when you're done - doesn't have this problem.

My guess is that you are doing 2 unusual things

1. Create PR with your first bit of work - and submitting everything to the same PR.
2. Using some tool or mechanism which makes every file change save directly to the repo - resulting in those PR updates.

[thabaum]

@iJungleboy

Apologies for the multiple commits in one PR today—better than none, right? 😉

Each commit could have been a separate PR for individual issues resolved, but I only realized these fixes were needed later as I worked through them.

This ties into a larger issue: when rebuilding something as large as the Oqtane Framework (e.g., during beta), every fix generates an email to contributors. During major overhauls, this can lead to a flood of notifications. To manage this, I’ve set up an email rule that pushes all Oqtane-related notifications into a dedicated folder, letting me browse updates without overwhelming my inbox.

As I contribute less frequently now, this may seem like the issue is "resolved." However, fewer contributions could be the unintended consequence of avoiding excessive notifications.

For example, with one PR:

• The initial submission sends one notification.
• Additional PRs or commits send more notifications, whether as part of the same PR or a new one.

This creates a dilemma: do I keep contributing knowing it might cause notification fatigue for others?

In past experiences, tools like the GitHub Pull Request extension may trigger numerous notifications if tracking all changes. However, it seems most emails are sent only for commits after the initial PR creation. Testing this further might clarify the behavior.

Going forward:

• I’ll try to consolidate changes using git commit for larger PRs or work on a branch until ready to push a complete PR. This limits notifications while still adhering to best practices.
• I’ll monitor notifications with the current documentation overhaul (a "mother load" of changes) to ensure things settle into smaller, manageable contributions.

While this PR combined multiple fixes, it was to reduce overhead for maintainers (you) to a single merge. Whether separate or combined, the number of emails remains the same. Let’s review how notifications are handled, especially as I plan larger contributions in the coming months. We can refine the contributions section if necessary to encourage smoother workflows for everyone.

Thank you for understanding, and I look forward to contributing more!

[iJungleboy]

this sounds good.

I suggest you submit the PR when you're done with work - basically before you "shut-down".

This way if you have a lot for a day / set-of-work, it's all together.