Issues and triaging features #12

Open
opened 2023-02-08 13:31:34 +01:00 by Brecht Van Lommel · 28 comments

High Priority

Asked Gitea developers to implement.

  • Embed videos in description and comments (upstream pull)
  • Canned responses (upstream issue)
  • Merge issue support without having to manually add label and comment. Issues should also show which other issues got merged into them, this is helpful info for triaging and bugfixing. One thing that is also missing is that users will not automatically get subscribed on the report that was merged into.
  • Remember comments when closing or reloading pages
  • Preview of markdown in issue and pull request forms
  • Ability to hide closed issues on project board
  • Can't move reports across repos, in particular between blender, addons and documentation. (wait and see how important, especially with upcoming extensions platform)

Medium Priority

  • Make commit hash clickable link in git notes
  • When reporting a bug through blenders UI, we still get phab-style syntax for the commit hash see here (blender/blender@64e4aed, only fixed for new builds)
  • Label menu apply/refresh behavior is clumsy (upstream pull that makes many improvements)
  • Improve video embedding to not require manually entering <video>
  • Markdown: fenced codeblocks with a lines info would be good (starting with e.g. ```lines=10) so we get a scrollbar
  • View list of branches and tags for a commit, instead of only one
  • “request” : remove user rights to assign projects in issues (should be using labels anyways)
  • If a user decides to report an issue via a project page (e.g. from blender/blender - blender - Blender Projects), then this will end up setting up the Project for this issue. This contradicts The Life of a Bug - Blender Developer Documentation “No Project is assigned to it”
    -- will add that to the first comment
  • Button to close issue as either resolved or archived, ideally as a native resolved / archived / merged state. Seems like a natural thing to do as part of the merging support. (upstream issue, upstream pull)
  • Summarize references of an issue instead of having to scroll through the entire comments
  • Date range support in issue list UI
  • Author filter (e.g. in Issues) is case-sensitive – unlike mentions with “@”

Low Priority

  • Apply label by pressing enter would be faster than mouse click
  • Close and comment right next to each other is causing confusion (being fixed upstream)
  • When an issue is renamed, it is listed multiple times in commit-notes-references, see here
  • Image comparisons are cumbersome since you can't flip between images using the arrow keys any longer
  • Filter menus on both /issues and /subscriptions pages, not just for issue list within repositories.
  • Quoting a comment doesn't show the author of the comment
  • Sort issues by priority
  • Have issue dependencies be graphable similar to Phabricator
  • Hide/disable due date for issues
  • Bug: Copy Link in dropzone only works once, see #12 (comment)
  • Make display of labels in project board optional, so more issues can be seen (upstream #22840)
  • Make project boards longer so more tasks can be seen simultaneously (upstream #22841)
  • Attachment URLs do not end in the original filename (for both human-readability and wget'ability) (upstream #10919)
  • Projects page and menus list projects by oldest, should be alphabetical to easily find them
  • Prevent non-developers from creating design/todo issues
  • Prevent creating default issues (upstream patch)
  • Comments on commits (not sure this worked well before, so might not want this)
  • T and D numbers in commits are not clickable (less important over time)
  • Alt click to remove scoped labels does not work on some browsers / OSes (#36)
  • List of edits on comments only highlights deletions, not additions, see here
  • Filtering labels in the "OR" style, the web UI always combines multiple labels using "AND", see here
  • Click scoped label to quickly change it to another label with the same scope
  • Tweak label colors to look better in light theme?
### High Priority Asked Gitea developers to implement. - [x] Embed videos in description and comments ([upstream pull](https://github.com/go-gitea/gitea/pull/22892)) - [ ] Canned responses ([upstream issue](https://github.com/go-gitea/gitea/issues/22787)) - [ ] Merge issue support without having to manually add label and comment. Issues should also show which other issues got merged into them, this is helpful info for triaging and bugfixing. One thing that is also missing is that users will not automatically get subscribed on the report that was merged into. - [ ] Remember comments when closing or reloading pages - [ ] Preview of markdown in issue and pull request forms - [x] Ability to hide closed issues on project board - [ ] Can't move reports across repos, in particular between blender, addons and documentation. (wait and see how important, especially with upcoming extensions platform) ### Medium Priority - [x] Make commit hash clickable link in git notes - [x] When reporting a bug through blenders UI, we still get phab-style syntax for the commit hash see [here](https://projects.blender.org/infrastructure/blender-projects-platform/issues/12#issuecomment-881955) (blender/blender@64e4aed, only fixed for new builds) - [x] Label menu apply/refresh behavior is clumsy ([upstream pull](https://github.com/go-gitea/gitea/pull/23014) that makes many improvements) - [x] Improve video embedding to not require manually entering `<video>` - [ ] Markdown: fenced codeblocks with a `lines` info would be good (starting with e.g. ```lines=10) so we get a scrollbar - [x] View list of branches and tags for a commit, instead of only one - [ ] “request” : remove user rights to assign projects in issues (should be using labels anyways) - [ ] If a user decides to report an issue via a project page (e.g. from blender/blender - blender - Blender Projects), then this will end up setting up the Project for this issue. This contradicts The Life of a Bug - Blender Developer Documentation “No Project is assigned to it” -- will add that to the first comment - [ ] Button to close issue as either resolved or archived, ideally as a native resolved / archived / merged state. Seems like a natural thing to do as part of the merging support. ([upstream issue](https://github.com/go-gitea/gitea/issues/22793), [upstream pull](https://github.com/go-gitea/gitea/pull/23522)) - [ ] Summarize references of an issue instead of having to scroll through the entire comments - [ ] Date range support in issue list UI - [ ] Author filter (e.g. in Issues) is case-sensitive – unlike mentions with “@” ### Low Priority - [x] Apply label by pressing enter would be faster than mouse click - [x] Close and comment right next to each other is causing confusion (being fixed upstream) - [x] When an issue is renamed, it is listed multiple times in commit-notes-references, see [here](https://projects.blender.org/infrastructure/blender-projects-platform/issues/12#issuecomment-881992) - [ ] Image comparisons are cumbersome since you can't flip between images using the arrow keys any longer - [ ] Filter menus on both `/issues` and `/subscriptions` pages, not just for issue list within repositories. - [ ] Quoting a comment doesn't show the author of the comment - [ ] Sort issues by priority - [ ] Have issue dependencies be graphable similar to Phabricator - [ ] Hide/disable due date for issues - [ ] Bug: Copy Link in dropzone only works once, see https://projects.blender.org/infrastructure/blender-projects-platform/issues/12#issuecomment-865290 - [x] Make display of labels in project board optional, so more issues can be seen ([upstream #22840](https://github.com/go-gitea/gitea/issues/22840)) - [x] Make project boards longer so more tasks can be seen simultaneously ([upstream #22841](https://github.com/go-gitea/gitea/issues/22841)) - [x] Attachment URLs do not end in the original filename (for both human-readability and wget'ability) ([upstream #10919](https://github.com/go-gitea/gitea/issues/10919)) - [ ] Projects page and menus list projects by oldest, should be alphabetical to easily find them - [ ] Prevent non-developers from creating design/todo issues - [x] Prevent creating default issues ([upstream patch](https://github.com/go-gitea/gitea/pull/20956)) - [ ] Comments on commits (not sure this worked well before, so might not want this) - [ ] T and D numbers in commits are not clickable (less important over time) - [x] Alt click to remove scoped labels does not work on some browsers / OSes (#36) - [ ] List of edits on comments only highlights deletions, not additions, see [here](https://projects.blender.org/infrastructure/blender-projects-platform/issues/12#issuecomment-883081) - [ ] Filtering labels in the "OR" style, the web UI always combines multiple labels using "AND", see [here](https://projects.blender.org/infrastructure/blender-projects-platform/issues/12#issuecomment-889875) - [ ] Click scoped label to quickly change it to another label with the same scope - [ ] Tweak label colors to look better in light theme?
Brecht Van Lommel changed title from Issues and Triaging Feature Requests to Issues and Triaging Features 2023-02-08 13:34:59 +01:00

Markdown: gitea claims to be compliant to commonmark via goldmark, I have tried many things which are just not working afaict, e.g. this example
(I was first interested to somehow get fenced codeblocks to take the max lines info that phabricator had (scrollbars on long codeblocks), turns out this is not possible? then tried with html div styles -- but styles seem to not work at all? am I missing something?)

Markdown: gitea claims to be compliant to [commonmark](https://spec.commonmark.org/0.30/) via [goldmark](https://github.com/yuin/goldmark), I have tried many things which are just not working afaict, e.g. [this example](https://spec.commonmark.org/0.30/#example-176) (I was first interested to somehow get fenced codeblocks to take the max lines info that phabricator had (scrollbars on long codeblocks), turns out this is not possible? then tried with html div styles -- but styles seem to not work at all? am I missing something?)
Author
Owner

What do you need for triaging to be effective? If it's that there is no way to add fenced codeblocks and that's a very useful feature for us, we should add it to the list.

However, "make the full commonmark standard work" is not something that I think we should add because it's potentially a lot of work with only minor benefit.

What do you need for triaging to be effective? If it's that there is no way to add fenced codeblocks and that's a very useful feature for us, we should add it to the list. However, "make the full commonmark standard work" is not something that I think we should add because it's potentially a lot of work with only minor benefit.

fenced codeblocks with a lines info would be good (starting with e.g. ```lines=10) so we get a scrollbar (currently ignored, se below). To my understanding, this is not even in the spec, but having an equivalent would work around trying to do this with other mardown things like div styles

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Will add to the list

fenced codeblocks with a `lines` info would be good (starting with e.g. ```lines=10) so we get a scrollbar (currently ignored, se below). To my understanding, this is not even in the spec, but having an equivalent would work around trying to do this with other mardown things like div styles ```lines=10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ``` Will add to the list

The "Copy Link" on attachments (once a file is uploaded in the dropzone) apparently only works the very first time using the dropbox, if you later edit the report description (or comment) again, that feature is gone (ref https://github.com/go-gitea/gitea/pull/22517)

The "Copy Link" on attachments (once a file is uploaded in the dropzone) apparently only works the very first time using the dropbox, if you later edit the report description (or comment) again, that feature is gone (ref https://github.com/go-gitea/gitea/pull/22517)
Brecht Van Lommel added the
gitea feature request
label 2023-02-08 16:54:39 +01:00

Another request that would be handy:
In commits, we now have every reference nicely visible as a block (thx to the bot adding the commit note)

image

In issues however, this is scattered in the whole discussion, so you have to scroll all your way through to know where this was referenced. It would help tremendously to see this in a single block (either just below the first comment or in the sidebar).

Not adding this to the list just yet, waiting for feedback if there is other ideas on this.

Another request that would be handy: In commits, we now have every reference nicely visible as a block (thx to the bot adding the commit note) ![image](/attachments/a4b0a232-2c02-4306-ae48-7e46325834e2) In issues however, this is scattered in the whole discussion, so you have to scroll all your way through to know where this was referenced. It would help tremendously to see this in a single block (either just below the first comment or in the sidebar). Not adding this to the list just yet, waiting for feedback if there is other ideas on this.

Yesterday it became clear to me that closing tasks is part of the comment box, as a red button right next to sending a comment ...

image

The action to close a task need to be somewhere else, imo at the bottom of the right side box.

Yesterday it became clear to me that closing tasks is part of the comment box, as a red button right next to sending a comment ... ![image](/attachments/8dea9663-7f28-4324-aca3-1e95d558a9b8) The action to close a task need to be somewhere else, imo at the bottom of the right side box.
3.1 KiB

Here is another one in relation to references:

While we have a flyover box to "expand" on the information of an issue (see screenshot below), there is no such thing for a commit or a PR (you are left with just the number -- having to click on the link for further info...) as we all know, clicking on a large commit can take a hug amount of time, just to see the title or author...

image

Here is another one in relation to references: While we have a flyover box to "expand" on the information of an **issue** (see screenshot below), there is no such thing for a **commit** or a **PR** (you are left with just the number -- having to click on the link for further info...) as we all know, clicking on a large commit can take a hug amount of time, just to see the title or author... ![image](/attachments/ec2053f2-b47c-43af-ae12-e6545ade4c09)

When reporting a bug through blenders UI, we still get phab-style syntax for the commit hash:

image

When reporting a bug through blenders UI, we still get phab-style syntax for the commit hash: ![image](/attachments/4a03f539-ce33-4206-a838-69312eaf80fc)

Issues: When reading notifications, the page may randomly switch.

Issues: When reading notifications, the page may randomly switch.

@mod_moder : the reload (after having made a change in that list) takes you back to page 1 ... not nice, just saying...

@mod_moder : the reload (after having made a change in that list) takes you back to page 1 ... not nice, just saying...

@lichtwerk It's strange, since I can make a lot of changes in time. Now it looks even weirder.

@lichtwerk It's strange, since I can make a lot of changes in time. Now it looks even weirder.

@brecht : when an issue is renamed, it is listed multiple times in commit-notes-references

image

@brecht : when an issue is renamed, it is listed multiple times in commit-notes-references ![image](/attachments/133d4239-0ee7-4624-b31b-c6b0a46de721)

More for the list: When typing an inline comment on a PR, ctrl+enter will submit as a comment, even though the "start review" button is highlighted as default button. "Start review" is also the desired default for ctrl+enter.

More for the list: When typing an inline comment on a PR, ctrl+enter will submit as a comment, even though the "start review" button is highlighted as default button. "Start review" is also the desired default for ctrl+enter.

More on references (see this for example): there is also no way to see if an issue already has a PR... you have to scroll all the way through the discussion...

More on references (see [this](https://projects.blender.org/infrastructure/blender-projects-platform/issues/12#issuecomment-880326) for example): there is also no way to see if an issue already has a PR... you have to scroll all the way through the discussion...

OK, so when you see a list of edits in a comment, the highlighting only works for deletions -- not additions):

image

image

OK, so when you see a list of edits in a comment, the highlighting only works for deletions -- not additions): ![image](/attachments/2f12b992-0676-4cd2-be90-5c7f4ad67d1e) ![image](/attachments/ded48707-870f-48d0-a3c6-3b86a90e549d)

No way to see tags in commits, so you cant see quickly if a commit is in a particular release. This is what phabricator had:

image

As a workaround, I found git tag --contains <commit> which is the poor mans workaround for now...

EDIT: this is working now

image
image

No way to see tags in commits, so you cant see quickly if a commit is in a particular release. This is what phabricator had: ![image](/attachments/b2fc4b4e-2279-465f-bf59-2523b9dec65e) As a workaround, I found `git tag --contains <commit>` which is the poor mans workaround for now... EDIT: this is working now ![image](/attachments/8f11d6db-e9fb-43cd-9774-af5598726ef4) ![image](/attachments/9f75560f-3573-40c8-9c73-47fdab34b887)

While the API provides filtering labels in the "OR" style, the web UI always combines multiple labels using "AND".

This is what the web UI https://projects.blender.org/blender/blender/issues uses as syntax:
labels=369%2c383

The API seems to offer "OR" https://projects.blender.org/api/swagger#/issue/issueListIssues
The string spit out there is labels=383%2C+369
Tried that in the web UI, but either gives a 500 Internal server error or still uses "AND". Also tried labels=369%2c%2b383 to no avail.

For finding issues tagged with either of multiple labels (say Interest/Geometry Nodes OR Interest/Nodes & Physics OR Module/Nodes & Physics) this would be extremely helpful. There does not seem to be a way to do this atm (well except for using the API - but I dont consider his a valid workflow for everyday work).

While the API provides filtering labels in the "OR" style, the web UI always combines multiple labels using "AND". This is what the web UI https://projects.blender.org/blender/blender/issues uses as syntax: `labels=369%2c383` The API seems to offer "OR" https://projects.blender.org/api/swagger#/issue/issueListIssues The string spit out there is `labels=383%2C+369` Tried that in the web UI, but either gives a 500 Internal server error or still uses "AND". Also tried `labels=369%2c%2b383` to no avail. For finding issues tagged with either of multiple labels (say `Interest/Geometry Nodes` OR `Interest/Nodes & Physics` OR `Module/Nodes & Physics`) this would be extremely helpful. There does not seem to be a way to do this atm (well except for using the API - but I dont consider his a valid workflow for everyday work).
Author
Owner

The parenthesis for such a feature should probably go like this:

bug AND confirmed AND (interest/nodes OR interest/physics OR module/nodes)
The parenthesis for such a feature should probably go like this: ``` bug AND confirmed AND (interest/nodes OR interest/physics OR module/nodes) ```
Brecht Van Lommel changed title from Issues and Triaging Features to Issues and triaging features 2023-03-09 23:59:35 +01:00

On various issues when editing a comment, it will remove all attached images.
I can't reliably reproduce it but it happens quite often.
Can anyone else confirm this?

On various issues when editing a comment, it will remove all attached images. I can't reliably reproduce it but it happens quite often. Can anyone else confirm this?

On various issues when editing a comment, it will remove all attached images.
I can't reliably reproduce it but it happens quite often.
Can anyone else confirm this?

I think something like that happened here blender/blender#105555 (comment) (comment is edited, pics/attachments are "Not Found")

> On various issues when editing a comment, it will remove all attached images. > I can't reliably reproduce it but it happens quite often. > Can anyone else confirm this? I think something like that happened here https://projects.blender.org/blender/blender/issues/105555#issuecomment-910354 (comment is edited, pics/attachments are "Not Found")

Will go over additional things we discussed in https://devtalk.blender.org/t/2024-02-15-triaging-module-meeting/33113:

  • “bug”: subscriptions, filter by tag > 2nd page resets filters
    -- this would be solved by "Filter menus on both /issues and /subscriptions pages, not just for issue list within repositories." already mentioned in the first comment, however even without the filter menus, it would be useful to keep the labels on the second page
  • “request” : improved filtering still (e.g. by dates)
    -- this would be solved by "Date range support in issue list UI" already mentioned in the first comment
  • “request” : be more restrictive to improve report quality
    -- this is more or less handled in #78 now
  • “request” : references “bundled” in a sidebar of issues (so you dont have to scroll the whole page)
    -- this is already mentioned as "Summarize references of an issue instead of having to scroll through the entire comments", this would be useful for PRs as well, will add to the first comment
  • “request” : make duplicates distinctive (not only references)
    -- this is more or less handled by "Merge issue support without having to manually add label and comment" already mentioned in the first comment
  • “request” : move reports across repos (blender >> addons or vice versa, also documentation)
    -- this is already mentioned as "Can't move reports across repos, in particular between blender, addons and documentation" in the first comment
  • “request” : remove user rights to assign projects in issues (should be using labels anyways)
    -- will add that to the first comment
  • “request” : remove user rights to reopen (debatable)
    -- this should have a further discussion first, personally, I would think this should not be changed (users should still e allowed to reopen reports)
  • “bug” : reopening: does not restore status labels correctly
    -- probably debatable, but it always goes to Needs Triage (even if it was confirmed before), will double-check in todays meeting

From https://devtalk.blender.org/t/2024-02-29-triaging-module-meeting/33580:

  • If a user decides to report an issue via a project page (e.g. from blender/blender - blender - Blender Projects), then this will end up setting up the Project for this issue. This contradicts The Life of a Bug - Blender Developer Documentation “No Project is assigned to it”
    -- will add that to the first comment

So many of these things were already on the list, just reconfirms that they are still an issue in the everyday triaging workflow :)

Will go over additional things we discussed in https://devtalk.blender.org/t/2024-02-15-triaging-module-meeting/33113: - “bug”: subscriptions, filter by tag > 2nd page resets filters -- this would be solved by "Filter menus on both /issues and /subscriptions pages, not just for issue list within repositories." already mentioned in the first comment, however even without the filter menus, it would be useful to keep the labels on the second page - “request” : improved filtering still (e.g. by dates) -- this would be solved by "Date range support in issue list UI" already mentioned in the first comment - “request” : be more restrictive to improve report quality -- this is more or less handled in #78 now - “request” : references “bundled” in a sidebar of issues (so you dont have to scroll the whole page) -- this is already mentioned as "Summarize references of an issue instead of having to scroll through the entire comments", this would be useful for PRs as well, will add to the first comment - “request” : make duplicates distinctive (not only references) -- this is more or less handled by "Merge issue support without having to manually add label and comment" already mentioned in the first comment - “request” : move reports across repos (blender >> addons or vice versa, also documentation) -- this is already mentioned as "Can't move reports across repos, in particular between blender, addons and documentation" in the first comment - “request” : remove user rights to assign projects in issues (should be using labels anyways) -- will add that to the first comment - “request” : remove user rights to reopen (debatable) -- this should have a further discussion first, personally, I would think this should not be changed (users should still e allowed to reopen reports) - “bug” : reopening: does not restore status labels correctly -- probably debatable, but it always goes to `Needs Triage` (even if it was confirmed before), will double-check in todays meeting From https://devtalk.blender.org/t/2024-02-29-triaging-module-meeting/33580: - If a user decides to report an issue via a project page (e.g. from blender/blender - blender - Blender Projects), then this will end up setting up the Project for this issue. This contradicts The Life of a Bug - Blender Developer Documentation “No Project is assigned to it” -- will add that to the first comment So many of these things were already on the list, just reconfirms that they are still an issue in the everyday triaging workflow :)
Author
Owner

Thanks for the overview. Feel free to edit the issue description and reorder things as needed there, to better reflect the priorities of the triaging module.

It could be a good topic for the next admin meeting to discuss if and how we can address these. I'd rather not spend time on implementing these types of things myself, but maybe some other solution can be found.

Thanks for the overview. Feel free to edit the issue description and reorder things as needed there, to better reflect the priorities of the triaging module. It could be a good topic for the next admin meeting to discuss if and how we can address these. I'd rather not spend time on implementing these types of things myself, but maybe some other solution can be found.

From https://devtalk.blender.org/t/2024-04-18-triaging-module-meeting/34260 :

  • Author filter (e.g. in Issues) is case-sensitive – unlike mentions with “@”
    -- will add that to the list
  • Unable to add certain users as reviewers -- -- which team membership is required?
  • Unable to assign non-devs to issues (e.g. on Good First Issues) -- which team membership is required?
  • Unable to remove reviewers from PRs -- -- which team membership is required?
From https://devtalk.blender.org/t/2024-04-18-triaging-module-meeting/34260 : - Author filter (e.g. in Issues) is case-sensitive – unlike mentions with “@” -- will add that to the list - Unable to add certain users as reviewers -- -- which team membership is required? - Unable to assign non-devs to issues (e.g. on `Good First Issues`) -- which team membership is required? - Unable to remove reviewers from PRs -- -- which team membership is required?
Author
Owner
  • Unable to add certain users as reviewers -- -- which team membership is required?

It seems to be anyone that is a member of some team in the Blender organization.

  • Unable to assign non-devs to issues (e.g. on Good First Issues) -- which team membership is required?

Anyone with write access to issues. Which is mainly Developers and Contributors teams.

  • Unable to remove reviewers from PRs -- -- which team membership is required?

Only admins and the reviewers themselves. The reason is that in Gitea you can set up rules about when a PR can be landed based on reviewer approvals or rejection, and so it shouldn't be possible for the author or another developer to bypass that by removing reviewers.

> - Unable to add certain users as reviewers -- -- which team membership is required? It seems to be anyone that is a member of some team in the Blender organization. > - Unable to assign non-devs to issues (e.g. on `Good First Issues`) -- which team membership is required? Anyone with write access to issues. Which is mainly Developers and Contributors teams. > - Unable to remove reviewers from PRs -- -- which team membership is required? Only admins and the reviewers themselves. The reason is that in Gitea you can set up rules about when a PR can be landed based on reviewer approvals or rejection, and so it shouldn't be possible for the author or another developer to bypass that by removing reviewers.
@PratikPB2123 ^^

make sense, Thanks 🙂

make sense, Thanks 🙂

There has been interest from a few members now for the option to subscribe to labels (E.g. Subscribe to the Module|Render & Cycles label) so users can recieved notifications on anything that happens with those labels (E.g. Someone comments on a issue with that label)

I have created a script that can generally do this, however it would be better if this was integrated into Gitea. I have a few questions related to this.

  • Is there already a option to do this and we just haven't found it?
  • If there isn't an option to do this, should we make a feature request to Gitea upstream?
    • Would you like me to do that? Or is it better coming from someone at the Blender foundation?
  • If the Gitea developers don't want to implement the feature, would they be willing to expand the Gitea API to make it work better for our needs?
    • My script makes a API call to https://projects.blender.org/api/v1/orgs/blender/activities/feeds to get recent activity. The adding and removing of labels is not included in the activity feed. If that information could be added to the activity feed in the Gitea API, that would be helpful.
    • My scipt has to make extra API calls to find the direct link to a comment because it's not included in https://projects.blender.org/api/v1/orgs/blender/activities/feeds (the comment_id field that should have that info, is always 0). This might be a bug in the current version of Gitea, or a TODO that hasn't been finished yet. If this could be fixed, I could reduce the number of API calls I make.
  • In the meantime, is their interest from the Blender foundation for using something like my script to create "per label activity feeds" on Blender chat, or a mailing list for different labels?
There has been interest from a few members now for the option to subscribe to labels (E.g. Subscribe to the `Module|Render & Cycles` label) so users can recieved notifications on anything that happens with those labels (E.g. Someone comments on a issue with that label) I have [created a script](https://projects.blender.org/Alaska/blender-activity-tracker) that can generally do this, however it would be better if this was integrated into Gitea. I have a few questions related to this. - Is there already a option to do this and we just haven't found it? - If there isn't an option to do this, should we make a feature request to Gitea upstream? - Would you like me to do that? Or is it better coming from someone at the Blender foundation? - If the Gitea developers don't want to implement the feature, would they be willing to expand the Gitea API to make it work better for our needs? - My script makes a API call to `https://projects.blender.org/api/v1/orgs/blender/activities/feeds` to get recent activity. The adding and removing of labels is not included in the activity feed. If that information could be added to the activity feed in the Gitea API, that would be helpful. - My scipt has to make extra API calls to find the direct link to a comment because it's not included in `https://projects.blender.org/api/v1/orgs/blender/activities/feeds` (the `comment_id` field that should have that info, is always 0). This might be a bug in the current version of Gitea, or a TODO that hasn't been finished yet. If this could be fixed, I could reduce the number of API calls I make. - In the meantime, is their interest from the Blender foundation for using something like my script to create "per label activity feeds" on Blender chat, or a mailing list for different labels?
Author
Owner

It would be a useful feature to add to Gitea. But unless there are multiple developers telling us this is very important for them, it's not something I want to prioritize, either as an upstream Gitea feature or something custom.

You're free to make the feature request upstream.

It would be a useful feature to add to Gitea. But unless there are multiple developers telling us this is very important for them, it's not something I want to prioritize, either as an upstream Gitea feature or something custom. You're free to make the feature request upstream.
Sign in to join this conversation.
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: infrastructure/blender-projects-platform#12
No description provided.