Custom Notifications Viewer

[0x4007]

• I did some research in the past with custom notifications viewer. feat: notifications ubiquity/work.ubq.fi#126
• Original specification here Notifications View/Filters ubiquity/work.ubq.fi#117

Fork work.ubq.fi because it has a lot of good qualities for list viewing, progressive web app features, styling etc. Tear out all the proposal/task related viewing logic, and focus only on notification viewing so that the code is simpler.

Custom Notifications Viewer

As activity continues to pick up and my notifications become slower to get through, it would be useful to make a simple ui that allows for more intelligent notification filtering.

Prioritization Sorting Algorithm

• We need to detect the priority level of the task the notification is associated with.
  • If the notification is not associated with a task, consider not showing it on this view at all.
  • If the notification is a pull request, it must be linked to a task with a priority label.
• Reverse chronological order, meaning that neglected/old notifications should appear higher than new ones.
  • The reason for this is that active conversations will continue to produce more notifications, which can easily cause the reviewer to check it multiple times in a sitting (as I try to get to inbox 0 this happens to me, so I intentionally start from older notifications for this reason.)
• Top of displayed list is highest priority, then work your way down to low priority.

Blocking Tasks

If it thinks without my input the task is blocked, it's a higher priority notification.

• Linkbacks: if the notification is associated with a task with many linkbacks then it should be considered higher priority, it usually means its blocking other pulls/tasks

Perhaps we could have an AI layer on top one day to summarize and/or reorder notifications from most important to least.

Remarks

• Always exclude draft pulls.

Notification Scoring

We should associate each notification with "scores" so that we can quantify where it would render on the page.

• Time score: the older it is, the higher its score. We can take the current posix timestamp and subtract the timestamp of the notification to achieve this.
• Linkback score: we can count how many times it was cross-referenced. The more times it was cross-referenced, the higher it should render on the page. We should prioritize those with higher linkbacks. If two notifications have the same amount of linkbacks i.e. 0, then we sort based on the time score only.

We need to ensure that priority level always has precedence. For example, priority 2 associated notifications should always appear higher than priority 1.

[ubiquity-os-beta]

@zugdev the deadline is at Wed, Dec 11, 9:25 AM UTC

[0x4007]

I decided to change this to 2 weeks because:

Forking from work.ubq.fi and cleaning things up will take a day, then the actual start of the work will begin later in the week. I realize that the scoring systems: 1. timestamp 2. linkback and 3. priority level alone might take a week to get right.

Timestamp is the least complex, priority linkback is probably next and then priority level is the most because it requires checking the associated issue and then reading its labels.

[zugdev]

1. First I fetch notifications from "GET /notifications" endpoint. (single request, pulls N objects)
2. Then I do some instant filtering like CI runs are out, all notifications that are not within Ubiquity organizations are out.
3. For each remaining notification I fetch it's pull. (let's assume N remaining notifications -> N requests)
4. For each pull, I check the body and pull the issue to see labels (N requests)

2N+1 reqs is not bad, the normal PAT allows 5k requests per hour, just gotta cache properly

[zugdev]

btw I am implementing at https://github.com/ubiquity/notifications.ubq.fi

[zugdev]

these are all the reasons a notification can be received for:

I thought of instantly filtering out: author, comment, ci_activity, invitation, member_feature_requested, security_advisory_credit, state_change, team_mention

[zugdev]

I am filtering out PR notifications which:

1. PR is in draft
2. PR is closed/merged
3. PR doesn't have a valid issue attached with Resolves

[0x4007]

Seems like you're on the right track!

[0x4007]

btw I am implementing at https://github.com/ubiquity/notifications.ubq.fi

Normally you should be working in your own org, and in a pull, and link it here. Eventually you need to link a pull anyways for code related tasks

[zugdev]

good! just to walkthrough my thoughts:

we will need to have 2 different "elements":

1. PR notifications

for these we have to fetch the PR object and scrape the issue URL from "Resolves (url or #number)", then we fetch the issue object. I am then bundling: notification + pr + issue in an aggregated type. this will allow me to get different properties from a single json object when rendering and caching: i.e issue labels, pr state, notification timestamp...

2. issue notifications

here we don't have to bundle PR, so it's a subset of the above.

---

features which could be cool in the future:

1. filtering out PR notifs where PR user is not the issue assignee

not yet implementable since disqualifier removes people

...

[0x4007]

Actually I think we should cache all the backend details (if any are missing) in the https://GitHub.com/ubiquity/devpool-directory cron job

Right now in the STORAGE branch I save all of the issue data which can be conveniently fetched in one shot. Don't handle these operations from the UI because it's a lot more efficient to cache and store in the repo.

So consider this as an option for aggregating all the data in one place in order to minimize network requests in the notifications UI.

[ubiquity-os-beta]

Passed the deadline and no activity is detected, removing assignees: @zugdev.

[0x4007]

@zugdev you need to link to prove progress to the OS

Team Member Nudging

A note I wanted to drop here: it would be really nice to have a feature where we can essentially "dm" an issue of interest and have it displayed in a highlighted or highly visible section with the name of the sender next to it.

A generic default UI we can model is an inbox with the persons GitHub profile and a timestamp.

The thing is in practice I've noticed that the team tends to send issues to each other in telegram DMs which seems to work as a concise nudge.

We can further clean our telegram dms by having this UI for this purpose.

[zugdev]

It's a great idea! Will link the PR

[zugdev]

/help

[ubiquity-os-beta]

Available Commands

Command	Description	Example
/help	List all available commands.	/help
/allow	Allows the user to modify the given label type.	/allow @user1 label

[zugdev]

@0x4007 when you see this, pls tag me in the issue and PR so I can copy the objects for QA. my inbox is empty

[0x4007]

@zugdev Issue tag here

[0x4007]

Accelerating Proposal Funding

Another later idea but we can make it a more formalized process for the necessary tags to be added.

• Priority tags by project managers.
• Time tags by technical team members.

It would be interesting one day to have a queue for proposals (GitHub issues) that are missing the other necessary tag to fund them.

For example, some have Time labels and then it's waiting on project managers to come in and set a Priority level so that it's funded.

This in addition to a financial incentive (somewhere between $5 and $25 to set a label) can potentially get proposals funded faster.

Contested Time Estimates

A tangent related to improving time estimate disputes: take the average between two time labels in case it's contested by collaborators. Perhaps one collaborator sets Time: <1 Hour and one sets Time: <4 Hours then we can set the time to 2.5 hours (the average of the two values) but in this case I suppose that the Time setters would need to split the monetary reward for setting the label.

[zugdev]

The first one can and should be embedded into the notifications UI! I think it should later become a guide to our contributors, admins and managers. I see the final product as a efficiency and productivity maximizer, which funnels effort into the appropriate places. This way I believe it could become a product in itself, useful for partners, and not only an internal tool.

To implement the first one we could have a cron job which is triggered when issues become a certain age, then we use a specific GitHub App to comment @managers. In the UI when we detect a notification triggered by the specific account, we treat it specially.

I believe the second idea is more plugin oriented.

[surafeldev]

/help

[ubiquity-os-beta]

Available Commands

Command	Description	Example
/help	List all available commands.	/help
/allow	Allows the user to modify the given label type.	/allow @user1 label

[surafeldev]

/help

[ubiquity-os-beta]

Available Commands

Command	Description	Example
/help	List all available commands.	/help
/allow	Allows the user to modify the given label type.	/allow @user1 label

[surafeldev]

/wallet 0xB13260bfEe08DcA208F2ECc735171B21763EaaF6

[henalolp]

/help

[ubiquity-os-beta]

Available Commands

Command	Description	Example
/help	List all available commands.	/help
/allow	Allows the user to modify the given label type.	/allow @user1 label

[0x4007]

@gentlementlegen looks like the config is broken here

[gentlementlegen]

@0x4007 this is the only plugin listed in the configuration file: https://github.com/ubiquity-os/.github/blob/main/.github/.ubiquity-os.config.dev.yml

[0x4007]

Right I see. The config merging is not implemented yet. Would you be able to render and push the full config for this repo?

[gentlementlegen]

Will have a look at the merging as soon as I am done with the current assigned issues I have. I will updated this to have the full config. We didn't deploy the configuration UI frotnend yet?

[gentlementlegen]

/help

[ubiquity-os-beta]

Available Commands

Command	Description	Example
/help	List all available commands.	/help
/allow	Allows the user to modify the given label type.	/allow @user1 label
/ask	Ask any question about the repository, issue or pull request	/ask
/query	Returns the user's wallet, access, and multiplier information.	/query @UbiquityOS
/start	Assign yourself and/or others to the issue/task.	/start
/stop	Unassign yourself from the issue/task.	/stop
/wallet	Register your wallet address for payments. Use '/wallet unset' to unlink your wallet.	/wallet ubq.eth

[0x4007]

Will have a look at the merging as soon as I am done with the current assigned issues I have. I will updated this to have the full config. We didn't deploy the configuration UI frotnend yet?

I don't think it's mapped to a URL yet, just some cloudflare link

[sura1-0-1]

/help