Spliting Forgejo runner feature requests in a dedicated issue tracker #369

earl-warren commented 2025年07月08日 16:09:08 +02:00

TL;DR:

Goal: avoid cluttering the Forgejo runner issue tracker with feature requests that have no followup.

• New ideas for Forgejo runner features are now filed in a dedicated issue tracker until they mature (most of them won't).
• Forgejo runner features requests can be filed when they have matured there.

---

Forgejo Actions is (just as Forgejo) getting ideas for features and there is no followup from the author in most cases. The best that happens is other users adding 👍 which does not help much in terms of figuring out the concrete problems / benefits it addresses. They accumulate indefinitely and the risk is to have hundreds of them lingering.

I'd like to avoid that for the Forgejo runner and take advantage of the fact there there are relatively few of those.

I'm going to do move the Forgejo runner feature requests (~25 of them 1 2) to a dedicated issue tracker.

That issue tracker has just two labels "Ideas" and "Mature". It is very coarse grain but more than enough to separate ideas that never had any followup (most of them) and those that got significant attention (a handful really).

It may be sensible to also move existing Forgejo feature requests related to Forgejo Actions there, but that requires more thought about how to articulate that with the design and user research issue trackers.

TL;DR: Goal: avoid cluttering the Forgejo runner issue tracker with feature requests that have no followup. - New ideas for Forgejo runner features are now filed in a [dedicated issue tracker](https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/new?template=.forgejo%2fissue_template%2ffeature-request.yaml) until they mature (most of them won't). - [Forgejo runner](https://code.forgejo.org/forgejo/runner/) features requests can be filed when they have matured there. --- Forgejo Actions is (just as Forgejo) getting ideas for features and there is no followup from the author in most cases. The best that happens is other users adding 👍 which does not help much in terms of figuring out the concrete problems / benefits it addresses. They accumulate indefinitely and the risk is to have hundreds of them lingering. I'd like to avoid that for the Forgejo runner and take advantage of the fact there there are relatively few of those. I'm going to do move the Forgejo runner feature requests (~25 of them [1](https://code.forgejo.org/forgejo/runner/issues?q=&type=all&sort=&labels=21&state=open&milestone=0&project=0&assignee=0&poster=0) [2](https://code.forgejo.org/forgejo/runner/issues?q=&type=all&sort=&labels=20&state=open&milestone=0&project=0&assignee=0&poster=0)) to a [dedicated issue tracker](https://code.forgejo.org/forgejo/runner-feature-requests/issues/new?template=.forgejo%2fissue_template%2ffeature-request.yaml). That issue tracker has just two labels "Ideas" and "Mature". It is very coarse grain but more than enough to separate ideas that never had any followup (most of them) and those that got significant attention (a handful really). It may be sensible to also move existing Forgejo feature requests related to Forgejo Actions there, but that requires more thought about how to articulate that with the [design](https://codeberg.org/forgejo/design/) and [user research](https://codeberg.org/forgejo/user-research) issue trackers.

earl-warren commented 2025年07月08日 17:01:06 +02:00

To avoid splitting issues between the ACT repository and the runner repository while keeping the ACT issue tracker open for the benefit of renovate, an issue template configuration with no templates was pushed and looks like this.

image

Existing issues were moved to the runner tracker or to the feature request tracker.

To avoid splitting issues between the ACT repository and the runner repository while keeping the ACT issue tracker open for the benefit of renovate, [an issue template configuration with no templates was pushed](https://code.forgejo.org/forgejo/act/commit/d77afd36037d906a45d9d441636f282b23130f9e) and [looks like this](https://code.forgejo.org/forgejo/act/issues/new/choose).  Existing issues were moved to the runner tracker or to the feature request tracker.

earl-warren commented 2025年07月08日 19:01:12 +02:00

Scrubbed / moved around all feature requests from ACT and the runner. They are now in the dedicated issue tracker where they can get ready in their own time - 21 of them, that's not too much.

There still are a few feature requests (4) left in the repository because it did not feel useful to move them. Either because they are simple and the benefits are clear. Or because there were already long discussions.

Scrubbed / moved around all feature requests from ACT and the runner. They are now in [the dedicated issue tracker where they can get ready in their own time](https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues) - 21 of them, that's not too much. There still are a few feature requests (4) left in the repository because it did not feel useful to move them. Either because they are simple and the benefits are clear. Or because there were already long discussions.

fnetX commented 2025年07月09日 15:40:38 +02:00

I would still be in favour of

• having one place for all feature requests, especially because not all feature requests related to Forgejo Actions need changes in the runner (some need UI changes, Forgejo backend changes or a coordination of the forgejo/runner/act)
• Separating all feature requests from Forgejo, so the Forgejo issue tracker only contains confirmed actionable items

I would still be in favour of * having one place for all feature requests, especially because not all feature requests related to Forgejo Actions need changes in the runner (some need UI changes, Forgejo backend changes or a coordination of the forgejo/runner/act) * Separating all feature requests from Forgejo, so the Forgejo issue tracker only contains confirmed actionable items

earl-warren commented 2025年07月09日 17:50:54 +02:00

I think it would make sense, if only as a way to not be flooded with ideas that (however good) have no followup beyond the first message. What I'm not sure about is:

• How to move existing feature requests it in a way that is not perceived as rejection by the author / participants of the feature request? IIRC previous attempts were unsuccessful at that.
• User Research and Design both have a learning curve so high that they feel like unnecessary / out of proportion to most people. How to pave the path by small and simple incremental paths that would lead to a mature feature request with a definition effort proportionate to its size?

I think it would make sense, if only as a way to not be flooded with ideas that (however good) have no followup beyond the first message. What I'm not sure about is: - How to move existing feature requests it in a way that is not perceived as rejection by the author / participants of the feature request? IIRC previous attempts were unsuccessful at that. - User Research and Design both have a learning curve so high that they feel like unnecessary / out of proportion to most people. How to pave the path by small and simple incremental paths that would lead to a mature feature request with a definition effort proportionate to its size?

sclu1034 commented 2025年07月09日 22:22:39 +02:00

As someone who is still close enough to the user perspective, I am confused as to why/how you expect the author to follow up without any comment by a maintainer/contributor to prompt them to do so.

If there is an issue template and I fill that out to the best of my knowledge, or if there was a comment by someone else that I answered to the best of my knowledge, I consider the ball in the project's court.
Without a comment from someone else, nothing would suggest to me that I should keep adding more comments, let alone would I know what these comments should contain.

Except for two, in all of the feature requess you linked in the runner, the author was (in my opinion justifiably) waiting for someone else to comment. Even if that was something like "can you provide X please?".

As someone who is still close enough to the user perspective, I am confused as to why/how you expect the author to follow up without any comment by a maintainer/contributor to prompt them to do so. If there is an issue template and I fill that out to the best of my knowledge, or if there was a comment by someone else that I answered to the best of my knowledge, I consider the ball in the project's court. Without a comment from someone else, nothing would suggest to me that I should keep adding more comments, let alone would I know what these comments should contain. Except for two, in all of the feature requess you linked in the runner, the author was (in my opinion justifiably) waiting for someone else to comment. Even if that was something like "can you provide X please?".

earl-warren commented 2025年07月09日 22:49:49 +02:00

@sclu1034 wrote in #369 (comment):

Except for two, in all of the feature requess you linked in the runner, the author was (in my opinion justifiably) waiting for someone else to comment. Even if that was something like "can you provide X please?".

I agree. And I attempted to remedy that in the newer template. To clarify that voicing an idea is only the beginning. Not to put pressure on the person who voiced the idea too much: anyone can provide more first hand evidence of a problem. But precisely to try to send a message that the best way to move forward is to keep accumulating evidence. Of course engaging in a conversation also works, but it is - by far - not the easier nor the most efficient way. Since, in the end, what will happen is likely that more evidence will need to be collected anyway.

It is very likely that my attempt is not optimal and needs tweaking. Or maybe another approach would work best. What is crystal clear is that the current approach is failing. Hundreds of feature requests where users could make progress by providing first hand testimonies but they don't and that opportunity for progress is missed. And hundreds of people who took time to file those features requests and feel both blocked and neglected because they don't see they have a simple way to make progress.

How to change that is the big question.

@sclu1034 wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5771339: > Except for two, in all of the feature requess you linked in the runner, the author was (in my opinion justifiably) waiting for someone else to comment. Even if that was something like "can you provide X please?". I agree. And I attempted to remedy that in [the newer template](https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/new?template=.forgejo%2fissue_template%2ffeature-request.yaml). To clarify that voicing an idea is only the beginning. Not to put pressure on the person who voiced the idea too much: anyone can provide more first hand evidence of a problem. But precisely to try to send a message that the best way to move forward is to keep accumulating evidence. Of course engaging in a conversation also works, but it is - by far - not the easier nor the most efficient way. Since, in the end, what will happen is likely that more evidence will need to be collected anyway. It is very likely that my attempt is not optimal and needs tweaking. Or maybe another approach would work best. What is crystal clear is that the current approach is failing. Hundreds of feature requests where users could make progress by providing first hand testimonies but they don't and that opportunity for progress is missed. And hundreds of people who took time to file those features requests and feel both blocked and neglected because they don't see they have a simple way to make progress. How to change that is the big question.

earl-warren commented 2025年07月09日 23:05:00 +02:00

@sclu1034 wrote in #369 (comment):

Even if that was something like "can you provide X please?".

The ask will invariably be "In addition to your own first hand testimony, others will be necessary to show variation of the problem this feature solves or the benefits it brings. It is unlikely to be ready until this happens. You can either wait for that to happen spontaneously. Or you can reach out to other users and convince them to add their own first hand testimony."

As a developer, I would be a lot more motivated to spend time on an idea if there was just two people telling how they faced the problem and how they had to work around it. Because in the overwhelming majority of cases this turns into a heads up dialog of opinions between two people which is not how it should be.

@sclu1034 wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5771339: > Even if that was something like "can you provide X please?". The ask will invariably be "In addition to your own first hand testimony, others will be necessary to show variation of the problem this feature solves or the benefits it brings. It is unlikely to be ready until this happens. You can either wait for that to happen spontaneously. Or you can reach out to other users and convince them to add their own first hand testimony." As a developer, I would be a lot more motivated to spend time on an idea if there was just **two** people telling how they faced the problem and how they had to work around it. Because in the overwhelming majority of cases this turns into a heads up dialog of opinions between two people which is not how it should be.

sclu1034 commented 2025年07月10日 12:02:58 +02:00

@earl-warren wrote in #369 (comment):

Not to put pressure on the person who voiced the idea too much

I believe that most people will consider this high pressure. I certainly would. This rather formal process that Forgejo uses is very rare in my experience, and therefore unknown to most people. And yet you're rolling a lot of it onto them.
I'd expect that to both stifle their motivation, and to provide worse results overall, since you're asking issue authors to do their own user research when most of them probably don't know how to do that.

@earl-warren wrote in #369 (comment):

And hundreds of people who took time to file those features requests and feel both blocked and neglected because they don't see they have a simple way to make progress.

They didn't see it because it is neither common nor self-evident, and they needed to be guided. And I don't think it is simple.

For example, I'm self-hosting an instance of ArchiveBox, and I've opened feature requests for that in the past. But I don't engage in their community, and I don't know anyone else who uses it.
So if I as the issue author was required to find other people to support my requests, that would be a huge barrier. I don't know anyone that I could ask for a legitimate opinion on my request, and I'm not going to pick out and message strangers from the issue tracker or a chat room just to find one.
After all, if one of those people did have the same need as me, they would have opened the request before me. So with 0 people to ask for, I would simply not be able to fulfill the requirement, ever. Wording that made me alone responsible for the requirement would merely mean that I might as well not open the request to begin with.

As such, I would expect a requirement for second opinions to result in most feature requests lying dormant until that second person comes around naturally and without affiliation with the author (the people that give 👍).

@earl-warren wrote in #369 (comment):

The ask will invariably be "In addition to your own first hand testimony, others will be necessary to show variation of the problem this feature solves or the benefits it brings. It is unlikely to be ready until this happens. You can either wait for that to happen spontaneously. Or you can reach out to other users and convince them to add their own first hand testimony."

Sure. And my point is that this ask needs to be made explicitly, because I do not expect the average user to just know it.
Though as explained above, I do not believe this would work if everything is rolled onto the author alone.

Rather, I would make it a short info for the author, like "Hi, thanks for your request. Please keep in mind that we usually wait for additional opinions to be able to properly flesh out a feature".
I would expect most people to be smart enough to realize that if they know someone they can ask them to provide that second opinion.

And then an info for everyone else, like "Hi, if you're interested in this feature request, or were about to give a 👍, please take a short minute to answer these two/three questions to help drive this feature forward: ...".

This could be something the issue templates adds to the top of the description automatically, or it could be an automated comment. Though I'd prefer the latter if I was the author, as it gives a feeling that my request was received and something has happened.

@earl-warren wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5771615: > Not to put pressure on the person who voiced the idea too much I believe that most people will consider this high pressure. I certainly would. This rather formal process that Forgejo uses is very rare in my experience, and therefore unknown to most people. And yet you're rolling a lot of it onto them. I'd expect that to both stifle their motivation, and to provide worse results overall, since you're asking issue authors to do their own user research when most of them probably don't know how to do that. @earl-warren wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5771615: > And hundreds of people who took time to file those features requests and feel both blocked and neglected because they don't see they have a simple way to make progress. They didn't see it because it is neither common nor self-evident, and they needed to be guided. And I don't think it is simple. For example, I'm self-hosting an instance of ArchiveBox, and I've opened feature requests for that in the past. But I don't engage in their community, and I don't know anyone else who uses it. So if I as the issue author was required to find other people to support my requests, that would be a huge barrier. I don't know anyone that I could ask for a legitimate opinion on my request, and I'm not going to pick out and message strangers from the issue tracker or a chat room just to find one. After all, if one of those people did have the same need as me, they would have opened the request before me. So with 0 people to ask for, I would simply not be able to fulfill the requirement, ever. Wording that made me alone responsible for the requirement would merely mean that I might as well not open the request to begin with. As such, I would expect a requirement for second opinions to result in most feature requests lying dormant until that second person comes around naturally and without affiliation with the author (the people that give 👍). @earl-warren wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5771747: > The ask will invariably be "In addition to your own first hand testimony, others will be necessary to show variation of the problem this feature solves or the benefits it brings. It is unlikely to be ready until this happens. You can either wait for that to happen spontaneously. Or you can reach out to other users and convince them to add their own first hand testimony." Sure. And my point is that this ask needs to be made explicitly, because I do not expect the average user to just know it. Though as explained above, I do not believe this would work if everything is rolled onto the author alone. Rather, I would make it a short info for the author, like "Hi, thanks for your request. Please keep in mind that we usually wait for additional opinions to be able to properly flesh out a feature". I would expect most people to be smart enough to realize that if they know someone they can ask them to provide that second opinion. And then an info for everyone else, like "Hi, if you're interested in this feature request, or were about to give a 👍, please take a short minute to answer these two/three questions to help drive this feature forward: ...". This could be something the issue templates adds to the top of the description automatically, or it could be an automated comment. Though I'd prefer the latter if I was the author, as it gives a feeling that my request was received and something has happened.

earl-warren commented 2025年07月10日 14:24:33 +02:00

I believe that most people will consider this high pressure. I certainly would. This rather formal process that Forgejo uses is very rare in my experience, and therefore unknown to most people. And yet you're rolling a lot of it onto them.

You are correct, I see that now.

For example, I'm self-hosting an instance of ArchiveBox, and I've opened feature requests for that in the past. But I don't engage in their community, and I don't know anyone else who uses it.

And that's also, of course, a position I'm in most of the time.

As such, I would expect a requirement for second opinions to result in most feature requests lying dormant until that second person comes around naturally and without affiliation with the author (the people that give 👍).

I think that is indeed inevitable and I also believe this should not be a problem. It is good to have feature requests that are marginally better than unfinished thought. A kind of pool of vague ideas floating around. What is not good is when this vast pool of ideas is perceived as being neglected and a source of frustration. This is where the difficulty is, IMHO.

A requirement for second opinions would be too much and too rigid. But prominently advertising that an idea with a second opinion (or more) immediately makes it stand out and become more likely to catch the eye of developers. This is in essence what User Research is about but it is not yet common knowledge and a lighter approach may have better chances of success.

This could be something the issue templates adds to the top of the description automatically, or it could be an automated comment. Though I'd prefer the latter if I was the author, as it gives a feeling that my request was received and something has happened.

That's an interesting thought.

---

I reworded and re-organized the template in a attempt to do that.

• Remove text so it is not too much to read
• Change the wording to be less demands / requirement and more about engaging in the first step of a process
• Using the passive form
• Changed the TODO list into a list of "What needs to happen" and move it towards the end

My intention is that

• someone filing a feature request has to provide just three things: first hand xp, needs and benefits, feature description and does not need to read too much
• someone frustrated because a months old feature did not get any attention can go back and see from the "What needs to happen" section that it is just waiting for more first hand testimony. And also see that if they are really frustrated, they can do something about it. That's going to be rare, of course, but it should be effective for people tempted to write a comment such as "it is a shame nothing is done" and be the one writing their own first hand experience instead, which would be a great shift of energy.
• someone discovering this feature request and adding a 👍 because they also need it can be asked to provide their first hand testimony by referring the description instead of manually explaining the same. In fact this could be done for some of the existing feature requests already.

I don't expect this new version to be final but I wonder if it addresses your concerns or if I'm still going in the wrong direction?

> I believe that most people will consider this high pressure. I certainly would. This rather formal process that Forgejo uses is very rare in my experience, and therefore unknown to most people. And yet you're rolling a lot of it onto them. You are correct, I see that now. > For example, I'm self-hosting an instance of ArchiveBox, and I've opened feature requests for that in the past. But I don't engage in their community, and I don't know anyone else who uses it. And that's also, of course, a position I'm in most of the time. > As such, I would expect a requirement for second opinions to result in most feature requests lying dormant until that second person comes around naturally and without affiliation with the author (the people that give 👍). I think that is indeed inevitable and I also believe this should not be a problem. It is good to have feature requests that are marginally better than unfinished thought. A kind of pool of vague ideas floating around. What is not good is when this vast pool of ideas is perceived as being neglected and a source of frustration. This is where the difficulty is, IMHO. A requirement for second opinions would be too much and too rigid. But prominently advertising that an idea with a second opinion (or more) immediately makes it stand out and become more likely to catch the eye of developers. This is in essence what User Research is about but it is not yet common knowledge and a lighter approach may have better chances of success. > This could be something the issue templates adds to the top of the description automatically, or it could be an automated comment. Though I'd prefer the latter if I was the author, as it gives a feeling that my request was received and something has happened. That's an interesting thought. --- I [reworded and re-organized the template](https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/commit/4f94563a977c45b7115aa76f9b3bb93b16c097e7) in a attempt to do that. - Remove text so it is not too much to read - Change the wording to be less demands / requirement and more about engaging in the first step of a process - Using the passive form - Changed the TODO list into a list of "What needs to happen" and move it towards the end My intention is that - someone filing a feature request has to provide just three things: first hand xp, needs and benefits, feature description and does not need to read too much - someone frustrated because a months old feature did not get any attention can go back and see from the "What needs to happen" section that it is just waiting for more first hand testimony. And also see that if they are really frustrated, they can do something about it. That's going to be rare, of course, but it should be effective for people tempted to write a comment such as "it is a shame nothing is done" and be the one writing their own first hand experience instead, which would be a great shift of energy. - someone discovering this feature request and adding a 👍 because they also need it can be asked to provide their first hand testimony by referring the description instead of manually explaining the same. In fact this could be done for some of the existing feature requests already. I don't expect this new version to be final but I wonder if it addresses your concerns or if I'm still going in the wrong direction?

Beowulf commented 2025年07月10日 14:29:59 +02:00

@earl-warren wrote in #369 (comment):

I think it would make sense, if only as a way to not be flooded with ideas that (however good) have no followup beyond the first message. What I'm not sure about is:

• How to move existing feature requests it in a way that is not perceived as rejection by the author / participants of the feature request? IIRC previous attempts were unsuccessful at that.

I would say if we want a tracker with just actionable items it should be a seperate tracker from the forgejo tracker.

Why?

1. No need to move existing tickets
2. Everyone who wants to open a ticket will first reach this tracker and create a ticket, we would need to close and move a lot of tickets
3. There is no increased workload for someone who wants to create an issue (no need to search where they are "allowed" to create a ticket

But I don't know if it would improve the situation if we have another tracker with actionable items. I think it is more a thing about using labels more extensive. Marking FR as not ready and when it is actionable marking it as such 🤔

@earl-warren wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5769272: > I think it would make sense, if only as a way to not be flooded with ideas that (however good) have no followup beyond the first message. What I'm not sure about is: > > * How to move existing feature requests it in a way that is not perceived as rejection by the author / participants of the feature request? IIRC previous attempts were unsuccessful at that. I would say if we want a tracker with just actionable items it should be a seperate tracker from the forgejo tracker. Why? 1. No need to move existing tickets 2. Everyone who wants to open a ticket will first reach this tracker and create a ticket, we would need to close and move a lot of tickets 3. There is no increased workload for someone who wants to create an issue (no need to search where they are "allowed" to create a ticket But I don't know if it would improve the situation if we have another tracker with actionable items. I think it is more a thing about using labels more extensive. Marking FR as not ready and when it is actionable marking it as such 🤔

sclu1034 commented 2025年07月10日 14:59:10 +02:00

Looks much better. Two minor things:

The section "A few other users contributed their own first hand experience." only talks about how the author themselves can go look for other people to comment. I still think calling out to the visitors that drop by after the issue was created would be more fruitful than trying to get the author to find supporters.
I.e. the "Hi, if you're interested in this feature request ..." part from above.

The section "The "Needs and benefit" and "Feature description" are reworded." is lacking conditionals, and therefore has the negative connotation of "we do not trust you to get the description right, it must be changed no matter what".
Instead maybe

1. **The "Needs and benefit" and "Feature description" are finalized.**
 Results from discussions and additional user experiences are incorporated into a final summary to provide a single reference for the developers working on this change.
 This can be done by the author of the issue or anyone else in a followup comment.

Looks much better. Two minor things: The section "A few other users contributed their own first hand experience." only talks about how the author themselves can go look for other people to comment. I still think calling out to the visitors that drop by after the issue was created would be more fruitful than trying to get the author to find supporters. I.e. the "Hi, if you're interested in this feature request ..." part from above. The section "The "Needs and benefit" and "Feature description" are reworded." is lacking conditionals, and therefore has the negative connotation of "we do not trust you to get the description right, it must be changed no matter what". Instead maybe ```md 1. **The "Needs and benefit" and "Feature description" are finalized.** Results from discussions and additional user experiences are incorporated into a final summary to provide a single reference for the developers working on this change. This can be done by the author of the issue or anyone else in a followup comment. ```

earl-warren commented 2025年07月10日 14:59:19 +02:00

Marking FR as not ready and when it is actionable marking it as such.

Yes, and that's what @fnetX has been doing for over a year now (with Gain/* labels). I'm not sure how successful it is globally. I'm using it and it helpful to me but I'm not sure if it is clear to someone adding a feature request. The main question being: how do I get from Gain/Undefined to something else?

> Marking FR as not ready and when it is actionable marking it as such. Yes, and that's what @fnetX has been doing for over a year now (with `Gain/*` labels). I'm not sure how successful it is globally. I'm using it and it helpful to me but I'm not sure if it is clear to someone adding a feature request. The main question being: how do I get from `Gain/Undefined` to something else?

fnetX commented 2025年07月10日 15:12:59 +02:00

you're asking issue authors to do their own user research when most of them probably don't know how to do that.

Note that this was never my intention. It is the task of the user research "team". Same as we don't ask people to implement the changes. But it's a necessary step in the process of feature requests, same as bugs need to be triaged in order to know if they are valid and reproducible.

However, I think this is better discussed in #178 to not bust the discussion about splitting the runner feature requests.

> you're asking issue authors to do their own user research when most of them probably don't know how to do that. Note that this was never my intention. It is the task of the user research "team". Same as we don't ask people to implement the changes. But it's a necessary step in the process of feature requests, same as bugs need to be triaged in order to know if they are valid and reproducible. However, I think this is better discussed in https://codeberg.org/forgejo/discussions/issues/178 to not bust the discussion about splitting the runner feature requests.

sclu1034 commented 2025年07月10日 15:31:47 +02:00

@fnetX wrote in #369 (comment):

Note that this was never my intention. It is the task of the user research "team".

I know. That's why I have been arguing that the wording didn't reflect that because it asked the author to do it.

@fnetX wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5777831: > Note that this was never my intention. It is the task of the user research "team". I know. That's why I have been arguing that the wording didn't reflect that because it asked the author to do it.

sclu1034 commented 2025年07月10日 15:38:49 +02:00

@earl-warren wrote in #369 (comment):

I'm not sure if it is clear to someone adding a feature request. The main question being: how do I get from Gain/Undefined to something else?

The way to make them sure about it would be to tell them. For example, an automated comment when the label gets applied that details the next steps. Or if a generic comment doesn't fit, the person applying the label has to detail the next steps manually. Or the issue template is adjusted to detail this from the start.

Basically the same thing as with the runner: Forgejo's process isn't commonly known, therefore it cannot be assumed that the user will implicitly know what to do, and instead extra effort needs to be made to tell them.

@earl-warren wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5777717: > I'm not sure if it is clear to someone adding a feature request. The main question being: how do I get from `Gain/Undefined` to something else? The way to make them sure about it would be to tell them. For example, an automated comment when the label gets applied that details the next steps. Or if a generic comment doesn't fit, the person applying the label has to detail the next steps manually. Or the issue template is adjusted to detail this from the start. Basically the same thing as with the runner: Forgejo's process isn't commonly known, therefore it cannot be assumed that the user will implicitly know what to do, and instead extra effort needs to be made to tell them.

earl-warren commented 2025年07月12日 15:56:51 +02:00

@sclu1034 wrote in #369 (comment):

The section "A few other users contributed their own first hand experience." only talks about how the author themselves can go look for other people to comment. I still think calling out to the visitors that drop by after the issue was created would be more fruitful than trying to get the author to find supporters. I.e. the "Hi, if you're interested in this feature request ..." part from above.

I thought of "you" as other people but evidently the first to read this will be the author of the feature request. It was changed to:

If you (the author of this feature request or someone interested in seeing it implemented) feel motivated to move this feature request forward, you can look for other users and kindly ask them to provide their own first hand experience.

If you have a better wording, please let me know.

@sclu1034 wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5777714: > The section "A few other users contributed their own first hand experience." only talks about how the author themselves can go look for other people to comment. I still think calling out to the visitors that drop by after the issue was created would be more fruitful than trying to get the author to find supporters. I.e. the "Hi, if you're interested in this feature request ..." part from above. I thought of "you" as other people but evidently the first to read this will be the author of the feature request. It was changed to: > If you (the author of this feature request or someone interested in seeing it implemented) feel motivated to move this feature request forward, you can look for other users and kindly ask them to provide their own first hand experience. If you have a better wording, please let me know.

earl-warren commented 2025年07月12日 16:00:49 +02:00

@sclu1034 wrote in #369 (comment):

The section "The "Needs and benefit" and "Feature description" are reworded." is lacking conditionals, and therefore has the negative connotation of "we do not trust you to get the description right, it must be changed no matter what". Instead maybe

1. **The "Needs and benefit" and "Feature description" are finalized.**
 Results from discussions and additional user experiences are incorporated into a final summary to provide a single reference for the developers working on this change.
 This can be done by the author of the issue or anyone else in a followup comment.

Better, copy/pasted.

@sclu1034 wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5777714: > The section "The "Needs and benefit" and "Feature description" are reworded." is lacking conditionals, and therefore has the negative connotation of "we do not trust you to get the description right, it must be changed no matter what". Instead maybe > > ```md > 1. **The "Needs and benefit" and "Feature description" are finalized.** > Results from discussions and additional user experiences are incorporated into a final summary to provide a single reference for the developers working on this change. > This can be done by the author of the issue or anyone else in a followup comment. > ``` Better, copy/pasted.

earl-warren commented 2025年07月12日 16:15:32 +02:00

@sclu1034 wrote in #369 (comment):

Basically the same thing as with the runner: Forgejo's process isn't commonly known, therefore it cannot be assumed that the user will implicitly know what to do, and instead extra effort needs to be made to tell them.

My hope (time will tell) is that the current template is simple enough. This is assuming that most people will go through at least one stage:

• Explain the feature request (it is common to all projects to ask that in one form or another, there won't be surprises, although the first hand experience is uncommon, I think it is trivial to get)

And some of them will go to a second stage when they come back weeks later to know if things made progress:

• Reading their feature request they will take a minute to read the steps
• They will know more first hand experiences are needed and that it can either happen by chance or because someone is motivated. I hope they will implicitly understand noone is tasked to do that. My hope is that they will not get frustrated because they expect someone in the project to spend time polishing this idea. The large majority of ideas are unfinished thoughts and, as an author of an idea, I would not expect that to happen. I would work myself on polishing that idea before I try to get the attention of someone and advocate that they would not be wasting their time if they looked into it.
• They will know this is a two stage process. Not a maze they can get lost in. Once first hand experiences are collected and the feature request is finalized, it is go for implementation time. That's it.

Of course I'm likely dreaming that it is that simple and reality will be different. But there is one thing that differentiate this process from all I've seen everywhere else: accumulation of first hand experiences. And maybe (just maybe) that will make a substantial difference.

@sclu1034 wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5778098: > Basically the same thing as with the runner: Forgejo's process isn't commonly known, therefore it cannot be assumed that the user will implicitly know what to do, and instead extra effort needs to be made to tell them. My hope (time will tell) is that the current template is simple enough. This is assuming that most people will go through at least one stage: - Explain the feature request (it is common to all projects to ask that in one form or another, there won't be surprises, although the first hand experience is uncommon, I think it is trivial to get) And some of them will go to a second stage when they come back weeks later to know if things made progress: - Reading their feature request they will take a minute to read the steps - They will know more first hand experiences are needed and that it can either happen by chance or because someone is motivated. I hope they will implicitly understand noone is tasked to do that. My hope is that they will not get frustrated because they expect someone in the project to spend time polishing this idea. The large majority of ideas are unfinished thoughts and, as an author of an idea, I would not expect that to happen. I would work myself on polishing that idea before I try to get the attention of someone and advocate that they would not be wasting their time if they looked into it. - They will know this is a **two stage** process. Not a maze they can get lost in. Once first hand experiences are collected and the feature request is finalized, it is go for implementation time. That's it. Of course I'm likely dreaming that it is that simple and reality will be different. But there is **one** thing that differentiate this process from all I've seen everywhere else: accumulation of first hand experiences. And maybe (just maybe) that will make a substantial difference.

earl-warren commented 2025年07月12日 16:23:47 +02:00

@fnetX the way I imagine user research / design fits is that it will work with the raw material (first hand experiences) that were collected. Instead of being forced get this raw data (polls, interviews, etc.). Most current feature request do not have that kind of raw data. They have abstract problems and abstract ideas and there is no clue if they even apply to the author of the feature request or how.

This raw data may not be enough and there may be a need to collect more. Or to ask their author to clarify a few things. But it won't be nothing and maybe (again just maybe) that will be a significant improvement over the current state of things.

@fnetX the way I imagine user research / design fits is that it will work with the raw material (first hand experiences) that were collected. Instead of being forced get this raw data (polls, interviews, etc.). Most current feature request do not have that kind of raw data. They have abstract problems and abstract ideas and there is no clue if they even apply to the author of the feature request or how. This raw data may not be enough and there may be a need to collect more. Or to ask their author to clarify a few things. But it won't be nothing and maybe (again just maybe) that will be a significant improvement over the current state of things.

sclu1034 commented 2025年07月14日 17:08:13 +02:00

@earl-warren wrote in #369 (comment):

I thought of "you" as other people but evidently the first to read this will be the author of the feature request. It was changed to:

The "you" and the "author is the first to read" aren't necessarily what makes this sound like it's addressed at the author only. The "look for other people" is, because usually a "bystander" isn't going to do something like that, making it the author by default.

An example I was thinking of is the "How to use GitHub" section in https://github.com/nextcloud/desktop/issues/7982.

With the list as is in your new template, it's probably hard to replicate a similar call-out to readers.
But going by Nextcloud's example, something like this in a separate, prominent place would have the most effect:

If you are interested in this feature request, or have a similar need, please provide your perspective by commenting below. You may use the sections from the issue description as guidelines.

As for the list at the bottom, maybe something like:

1. **A few other users contributed their own first hand experience.**
 To fully grasp the scope of a feature request, and to brainstorm possible solutions, a feature request will generally wait until several users have provided their perspective.
 Thumbs-up reactions help gauge popularity, but do not provide the same amount of useful information.

(not sure it it's the best wording, but the intent is to objectively state "it needs comments from other people", without any specific call-out like "you are responsible for bringing other people here").

I would expect issue authors to be clever enough to realize that they can shortcurcuit this by actively inviting people if they happen to know of them already, without the template having to tell them so.

@earl-warren wrote in #369 (comment):

• I hope they will implicitly understand noone is tasked to do that.

That's sort of my point the entire time: With how things were worded so far, it always reads like I (as the issue author) am tasked to do that.
As long as you're saying things like "you need to go find other people", it's a task. The options to not sound like that are

• passively catching the people that drop by eventually:
  "if you happen to read this and are interested, please take a minute to write a comment"
• objectively state requirements and let everyone figure out their own capacity for how they can comply:
  "at least three people need to comment"

@earl-warren wrote in #369 (comment):

• My hope is that they will not get frustrated because they expect someone in the project to spend time polishing this idea. The large majority of ideas are unfinished thoughts and, as an author of an idea, I would not expect that to happen. I would work myself on polishing that idea before I try to get the attention of someone and advocate that they would not be wasting their time if they looked into it.

In my experience, the vast majority of people do not think like that. They will voice their need, and they will be happy to provide things they are prompted for, but they have various reasons to not be as proactive as you want them to be.

They only have a limited view on the user base, so they couldn't properly flesh out the feature in a way that fits everyone.
They often know little to nothing about the code base, so their polishing could be miles off of what can actually be implemented.
They have their own ideas and perspective, so they cannot judge whether their requests are in line with the project.
And most of them have no idea how this process even works, so they fail at the simple step of not even knowing there is another step.

This would be similar to tech support demanding that every time a user comes to them with "my pc doesn't work", they must have already gone through the entire debugging check list, down to cross-testing the correct components for the issue (which would be awesome, but 90% of user have no clue what to do after "have you turned it off and on again?").

@earl-warren wrote in #369 (comment):

But there is one thing that differentiate this process from all I've seen everywhere else: accumulation of first hand experiences. And maybe (just maybe) that will make a substantial difference.

Yes, that's a rather unique part. But my expectation is that this makes it harder, not easier for people. It's something entirely unknown to them, so they need more guidance, not less.

@earl-warren wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5802134: > I thought of "you" as other people but evidently the first to read this will be the author of the feature request. It was changed to: The "you" and the "author is the first to read" aren't necessarily what makes this sound like it's addressed at the author only. The "look for other people" is, because usually a "bystander" isn't going to do something like that, making it the author by default. An example I was thinking of is the "How to use GitHub" section in https://github.com/nextcloud/desktop/issues/7982. With the list as is in your new template, it's probably hard to replicate a similar call-out to readers. But going by Nextcloud's example, something like this in a separate, prominent place would have the most effect: ```md If you are interested in this feature request, or have a similar need, please provide your perspective by commenting below. You may use the sections from the issue description as guidelines. ``` As for the list at the bottom, maybe something like: ```md 1. **A few other users contributed their own first hand experience.** To fully grasp the scope of a feature request, and to brainstorm possible solutions, a feature request will generally wait until several users have provided their perspective. Thumbs-up reactions help gauge popularity, but do not provide the same amount of useful information. ``` (not sure it it's the best wording, but the intent is to objectively state "it needs comments from other people", without any specific call-out like "you are responsible for bringing other people here"). I would expect issue authors to be clever enough to realize that they can shortcurcuit this by actively inviting people if they happen to know of them already, without the template having to tell them so. @earl-warren wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5802296: > * I hope they will implicitly understand noone is tasked to do that. That's sort of my point the entire time: With how things were worded so far, it always reads like I (as the issue author) _am_ tasked to do that. As long as you're saying things like "you need to go find other people", it's a task. The options to not sound like that are - passively catching the people that drop by eventually: "if you happen to read this and are interested, please take a minute to write a comment" - objectively state requirements and let everyone figure out their own capacity for how they can comply: "at least three people need to comment" @earl-warren wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5802296: > * My hope is that they will not get frustrated because they expect someone in the project to spend time polishing this idea. The large majority of ideas are unfinished thoughts and, as an author of an idea, I would not expect that to happen. I would work myself on polishing that idea before I try to get the attention of someone and advocate that they would not be wasting their time if they looked into it. In my experience, the vast majority of people do not think like that. They will voice their need, and they will be happy to provide things they are prompted for, but they have various reasons to not be as proactive as you want them to be. They only have a limited view on the user base, so they couldn't properly flesh out the feature in a way that fits everyone. They often know little to nothing about the code base, so their polishing could be miles off of what can actually be implemented. They have their own ideas and perspective, so they cannot judge whether their requests are in line with the project. And most of them have no idea how this process even works, so they fail at the simple step of not even knowing there is another step. This would be similar to tech support demanding that every time a user comes to them with "my pc doesn't work", they must have already gone through the entire debugging check list, down to cross-testing the correct components for the issue (which would be awesome, but 90% of user have no clue what to do after "have you turned it off and on again?"). @earl-warren wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5802296: > But there is **one** thing that differentiate this process from all I've seen everywhere else: accumulation of first hand experiences. And maybe (just maybe) that will make a substantial difference. Yes, that's a rather unique part. But my expectation is that this makes it harder, not easier for people. It's something entirely unknown to them, so they need _more_ guidance, not less.

earl-warren commented 2025年07月14日 17:41:08 +02:00

@sclu1034 wrote in #369 (comment):

@earl-warren wrote in #369 (comment):

I thought of "you" as other people but evidently the first to read this will be the author of the feature request. It was changed to:

The "you" and the "author is the first to read" aren't necessarily what makes this sound like it's addressed at the author only. The "look for other people" is, because usually a "bystander" isn't going to do something like that, making it the author by default.

An example I was thinking of is the "How to use GitHub" section in https://github.com/nextcloud/desktop/issues/7982.

With the list as is in your new template, it's probably hard to replicate a similar call-out to readers. But going by Nextcloud's example, something like this in a separate, prominent place would have the most effect:

I like how the callout is:

• At the top
• Clearly and simply separated ("Please keep this for other contributors")

If you are interested in this feature request, or have a similar need, please provide your perspective by commenting below. You may use the sections from the issue description as guidelines.

I went for a similar wording that asks for "first hand experience" rather than a more vague "perspective". To increase the likelyhood of having hard data / actual evidence rather than a debate of opinion alone.

As for the list at the bottom, maybe something like:

1. **A few other users contributed their own first hand experience.**
 To fully grasp the scope of a feature request, and to brainstorm possible solutions, a feature request will generally wait until several users have provided their perspective.
 Thumbs-up reactions help gauge popularity, but do not provide the same amount of useful information.

(not sure it it's the best wording, but the intent is to objectively state "it needs comments from other people", without any specific call-out like "you are responsible for bringing other people here").

I would expect issue authors to be clever enough to realize that they can shortcurcuit this by actively inviting people if they happen to know of them already, without the template having to tell them so.

I copy/pasted your wording. It is lighter and more gentle.

@earl-warren wrote in #369 (comment):

• I hope they will implicitly understand noone is tasked to do that.

That's sort of my point the entire time: With how things were worded so far, it always reads like I (as the issue author) am tasked to do that. As long as you're saying things like "you need to go find other people", it's a task. The options to not sound like that are

* passively catching the people that drop by eventually:
 "if you happen to read this and are interested, please take a minute to write a comment"
* objectively state requirements and let everyone figure out their own capacity for how they can comply:
 "at least three people need to comment"

I think with those latest changes we're closer to that. And I agree on your assessment.

@earl-warren wrote in #369 (comment):

But there is one thing that differentiate this process from all I've seen everywhere else: accumulation of first hand experiences. And maybe (just maybe) that will make a substantial difference.

Yes, that's a rather unique part. But my expectation is that this makes it harder, not easier for people. It's something entirely unknown to them, so they need more guidance, not less.

I'm unsure. I've really never came across a feature request that asks me to explain with a bullet list a first hand experience relevant to the feature I have in mind. But maybe it is not that hard. Of course I'm biased because it comes easy to me now. So maybe not.

Time will tell.

@sclu1034 wrote in https://codeberg.org/forgejo/discussions/issues/369#issuecomment-5825897: > @earl-warren wrote in #369 (comment): > > > I thought of "you" as other people but evidently the first to read this will be the author of the feature request. It was changed to: > > The "you" and the "author is the first to read" aren't necessarily what makes this sound like it's addressed at the author only. The "look for other people" is, because usually a "bystander" isn't going to do something like that, making it the author by default. > > An example I was thinking of is the "How to use GitHub" section in https://github.com/nextcloud/desktop/issues/7982. > > With the list as is in your new template, it's probably hard to replicate a similar call-out to readers. But going by Nextcloud's example, something like this in a separate, prominent place would have the most effect: I like how the callout is: - At the top - Clearly and simply separated ("Please keep this for other contributors") > ```md > If you are interested in this feature request, or have a similar need, please provide your perspective by commenting below. You may use the sections from the issue description as guidelines. > ``` I went for a similar wording that asks for "first hand experience" rather than a more vague "perspective". To increase the likelyhood of having hard data / actual evidence rather than a debate of opinion alone. > As for the list at the bottom, maybe something like: > > ```md > 1. **A few other users contributed their own first hand experience.** > To fully grasp the scope of a feature request, and to brainstorm possible solutions, a feature request will generally wait until several users have provided their perspective. > Thumbs-up reactions help gauge popularity, but do not provide the same amount of useful information. > ``` > > (not sure it it's the best wording, but the intent is to objectively state "it needs comments from other people", without any specific call-out like "you are responsible for bringing other people here"). > > I would expect issue authors to be clever enough to realize that they can shortcurcuit this by actively inviting people if they happen to know of them already, without the template having to tell them so. I copy/pasted your wording. It is lighter and more gentle. > > @earl-warren wrote in #369 (comment): > > > * I hope they will implicitly understand noone is tasked to do that. > > That's sort of my point the entire time: With how things were worded so far, it always reads like I (as the issue author) _am_ tasked to do that. As long as you're saying things like "you need to go find other people", it's a task. The options to not sound like that are > > * passively catching the people that drop by eventually: > "if you happen to read this and are interested, please take a minute to write a comment" > > * objectively state requirements and let everyone figure out their own capacity for how they can comply: > "at least three people need to comment" I think with those latest changes we're closer to that. And I agree on your assessment. > @earl-warren wrote in #369 (comment): > > > But there is **one** thing that differentiate this process from all I've seen everywhere else: accumulation of first hand experiences. And maybe (just maybe) that will make a substantial difference. > > Yes, that's a rather unique part. But my expectation is that this makes it harder, not easier for people. It's something entirely unknown to them, so they need _more_ guidance, not less. I'm unsure. I've really never came across a feature request that asks me to explain with a bullet list a first hand experience relevant to the feature I have in mind. But maybe it is not that hard. Of course I'm biased because it comes easy to me now. So maybe not. Time will tell.

sclu1034 commented 2025年07月15日 10:47:48 +02:00

The template looks much better now 👍
This should help avoid the deadlock that the feature requests you transferred had ended up in.

The template looks much better now 👍 This should help avoid the deadlock that the feature requests you transferred had ended up in.

earl-warren commented 2025年07月15日 14:29:41 +02:00

Now I'm eagerly waiting for the next feature request. Which I usually don't 😆

Now I'm eagerly waiting for the next feature request. Which I usually don't 😆

fnetX commented 2025年07月17日 03:26:41 +02:00

I'm still not 100% convinced that splitting the Forgejo Actions feature requests from other Forgejo feature requests is a good idea, but I'm still supportive of splitting feature requests from actionable tasks. This can act as a playground to fine-tune the workflow.

Now I'm eagerly waiting for the next feature request

Took the time to file one :)

BTW, the "static" sections in the issue template don't need to be editable by the user. They can also be statically inserted. You can use markdown and set the visibility to content or both. https://forgejo.org/docs/latest/user/issue-pull-request-templates/#markdown

I'm still not 100% convinced that splitting the Forgejo Actions feature requests from other Forgejo feature requests is a good idea, but I'm still supportive of splitting feature requests from actionable tasks. This can act as a playground to fine-tune the workflow. > Now I'm eagerly waiting for the next feature request Took the time to file one :) BTW, the "static" sections in the issue template don't need to be editable by the user. They can also be statically inserted. You can use markdown and set the visibility to content or both. https://forgejo.org/docs/latest/user/issue-pull-request-templates/#markdown