forgejo/discussions
49
43

Proposal: Issues, user research, design and implementation workflow #415

Open
opened 2025年11月10日 01:05:25 +01:00 by fnetX · 59 comments
Owner
Copy link

Hi! This is a continuation from #178 which I see replaced. I'm starting a new discussion because I feel like a cut makes sense. You can read the backlog, but it is not necessary.

The design workflows have changed organically recently, and I appreciate that a lot more contributors have engaged in the user-research and design issue trackers. Especially @earl-warren has increasingly asked users to explain their first-hand experience in issues, and I feel like this has not only simplified my work as a user researcher (so I can just look at text and don't have to send the same questions everywhere), but also helped other Forgejo contributors get inspiration from the actual problems users are facing.

I find the first-hand experience very inspiring and easier to reason about than some of the "Needs and benefits" section of feature requests. Many users still write the text in this section based on the common understanding of feature requests, thinking from the solution space instead of the problem space. I believe that "I run an organization and we use Y as a signin for all our services; we'd like to add Forgejo; we have already investigated these options" is much more valuable than "I want to integrate sign in with Y, because It will allow using your Y account to login to Forgejo".

Hereby, I have a proposal on how to integrate this into the normal Forgejo development cycle.

My vision for a workflow

Going forward, issues in Forgejo should take the following steps.

I'll introduce the following terms:

  • Problem: The user-facing part of a change. Users explain what they are struggling with.
  • Enhancement: The contributor-facing part of a change. Used for UX design or technical discussions.
  1. A user has a problem.
  2. They go to the issue tracker and search for related problems.
    • If they find one, they add their own experience to it.
    • If not, they create a new issue from the "Problem" template, which guides them into explaining the actual problem they are facing.
  3. Contributors triage the problem.
    • If it is an obvious issue ("bug"), it will be marked a bug.
    • If it is a bug that cannot be solved without design work (e.g. "This feature does not work", but it is not clear how it should actually work), it will get a different marker for needing design.
    • If the problem is not clear, it will remain in the "Problem" state, open for input from other users or the user research team
    • The severity of a problem can be classified (how many users are affected? How "bad" is it? Are workarounds available?) A severity label could be introduced.
  4. If someone got an inspiration, they
    • Create a new issue from the "Enhancement" template
    • An "Enhancement" MUST reference at least one existing problem, but can address multiple
    • Enhancements are not only specific to feature requests, they could also address confirmed scaling issues (e.g. a user reports slowness and the problem contains some investigation and logs; the related enhancement discusses whether a certain refactoring of a table solve the specific issue)
  5. Enhancements are classified by contributors
    • Does it indeed solve the problems?
    • How is the complexity? Is it feasible?
  6. The enhancement can be iterated or an enhanced enhancement proposed :)
  7. Enhancements get classified gains.
  8. Contributors are encouraged to pick enhancements with high gain. New contributors are encouraged to additionally filter for low complexity.
  9. Pull requests need to reference either an accepted enhancement OR a trivial problem ("bug" in step 3.1)
    • It is important that the workflow does not reduce productivity for obvious cases like regressions or simple bugs.
    • However, fast-tracking should only be done for few and small changes.
  10. Problems can be closed if Forgejo contributors do not plan to actively look for a solution to clear the backlog. However, closed problems are still valid user experience reports and can still allow to justify an enhancement, as long as an enhancement does not only address closed problems.
    • It is not valid to propose an enhancement to address a problem that was considered low severity.
    • However, it is valid to propose an enhancement that, among others, also improves the situation for a problem that was previously ignored.

Which problems does this solve?

  • Since Problems are the required first step, we get rid of feature requests and pull requests that serve no clear value
    • Currently, taking a step back and asking about the actual problem behind an idea requires "someone to be the bad guy", e.g. forgejo/forgejo#157 (comment) or forgejo/forgejo#10007 (comment)
    • Going forward, new contributors can simply be hinted towards a defined workflow and asked to complete the required steps to justify their idea or patch
  • The workflow focuses on having a clear workflow that every Forgejo contributor can follow and does not create a user-research bottleneck.
  • All contributors get a better understanding of how the design work should be conducted.
  • There is less confusion about "bugs" vs "feature requests" in some cases. The focus is on demonstrating that a change is worth the effort.
    • I feel like this is particularly important and addresses the "an existing behavior that is demonstrated to be confusing for users is considered to be a bug" from #337#
    • A small quality of life fix is equally suited as a first contribution, important is the confirmed gain and the complexity
  • Problems that are not severe enough to deserve a fix (e.g. "cannot integrate Forgejo with third-party platform xyz" or "I would like to schedule a meeting with Forgejo contributors") can get discarded earlier, before too much discussion went into the solution and technical details ("I need a calendar and an appointment feature")
  • Problems serve as an archive. Contrary to rejecting a feature request, closing a problem can still convey it as being acknowledged. Future enhancements can still refer to the first hand user experience of closed problems to justify the relevance.
  • Some requests, especially highly technical needs, are sometimes hard to be judged by the user research team, because it requires significant understanding of a certain domain (for example, I sometimes struggle to perform reasonable user research in the domain of CI/CD integrations)

How to get there?

  1. The issue templates are being reworked.
  2. Labels are created to allow classifying problems for the severity and enhancements for the complexity.
    • The gain/* labels could be kept for the enhancements.
    • New severity/* labels are introduced for problems.
    • New complexity/* labels are created.
    • The good first issue label could be renamed into complexity/easy-starter (or similar); or it could be kept additionally to not only mark simple fixes but ones that are good learning opportunities.
  3. Existing feature requests (~800) are triaged.
    • If they seem valuable and clear, existing feature requests get relabeled as an enhancement with no further adjustments.
    • If they seem valuable and can be clarified, a new enhancement is created referencing the previous feature request, and the old feature request is marked a problem
    • If they seem valuable but not clear, the issue remains open and the author is asked to clarify the problem using the new template.
    • Otherwise, the issue is closed and the author also asked to clarify the problem using the new template.
  4. My goal would be to classify 100 issues, then consider adjustments to the workflow (e.g. if some issue was still unclear on how to proceed); then proceed with the other backlog of issues over the next 6 months
  5. I am not yet sure how to proceed with the ~250 bug reports

Open questions

  • Should everything be done in the forgejo/forgejo repository?
    • I think it would be good enough with the use of labels and would avoid the need to tell people about the additional repositories.
  • What about forgejo/design?
    • I think I would prefer to move the discussions happening there back into the main issue tracker. It was a nice experiment, and now that contributors have picked it up, I feel like it's time to move the discussions where everyone can easily find them.
  • Who does the work?
    • Well, as indicated in #178, I'm very motivated to do a huge chunk of work related to this, including the preparation (labels + issue templates) and sorting the backlog (in many cases copy-pasting the same text and quickly deciding whether the issue gets closed or not)
    • I feel like the approach is good for distributing the work and reducing bottlenecks. Going forward, the work can be handled by everyone, even contributors with little free time.
  • What about bug reports?
    • Since my proposal will still have the bug labels, I think it's fine to keep them untouched at first.
    • They can still be classified later (maybe some bugs are rather problems and it is not yet clear if and how they should be fixed, but I think it is not urgent to do this work)

I'm looking forward to hearing your opinions. I'm very happy to refine the proposal, but I'd like to finally reach a conclusion. I have spent a lot of time thinking about this during the summer months and I hope the revised proposal will soon become a reality. Thank you!

Hi! This is a continuation from https://codeberg.org/forgejo/discussions/issues/178 which I see replaced. I'm starting a new discussion because I feel like a cut makes sense. You can read the backlog, but it is not necessary. The design workflows have changed organically recently, and I appreciate that a lot more contributors have engaged in the [user-research](https://codeberg.org/forgejo/user-research/issues/) and [design](https://codeberg.org/forgejo/design/issues/) issue trackers. Especially @earl-warren has increasingly asked users to explain their first-hand experience in issues, and I feel like this has not only simplified my work as a user researcher (so I can just look at text and don't have to send the same questions everywhere), but also helped other Forgejo contributors get inspiration from the actual problems users are facing. I find the first-hand experience very inspiring and easier to reason about than some of the "Needs and benefits" section of feature requests. Many users still write the text in this section based on the common understanding of feature requests, thinking from the solution space instead of the problem space. I believe that "I run an organization and we use Y as a signin for all our services; we'd like to add Forgejo; we have already investigated these options" is much more valuable than "I want to integrate sign in with Y, because [It will allow using your Y account to login to Forgejo](https://codeberg.org/forgejo/forgejo/issues/7436)". Hereby, I have a proposal on how to integrate this into the normal Forgejo development cycle. ### My vision for a workflow Going forward, issues in Forgejo should take the following steps. I'll introduce the following terms: * Problem: The user-facing part of a change. Users explain what they are struggling with. * Enhancement: The contributor-facing part of a change. Used for UX design or technical discussions. 1. A user has a problem. 2. They go to the issue tracker and search for related problems. * If they find one, they add their own experience to it. * If not, they create a new issue from the "Problem" template, which guides them into explaining the actual problem they are facing. 3. Contributors triage the problem. * If it is an obvious issue ("bug"), it will be marked a bug. * If it is a bug that cannot be solved without design work (e.g. "This feature does not work", but it is not clear how it should actually work), it will get a different marker for needing design. * If the problem is not clear, it will remain in the "Problem" state, open for input from other users or the user research team * The severity of a problem can be classified (how many users are affected? How "bad" is it? Are workarounds available?) A severity label could be introduced. 4. If someone got an inspiration, they * Create a new issue from the "Enhancement" template * An "Enhancement" MUST reference at least one existing problem, but can address multiple * Enhancements are not only specific to feature requests, they could also address confirmed scaling issues (e.g. a user reports slowness and the problem contains some investigation and logs; the related enhancement discusses whether a certain refactoring of a table solve the specific issue) 5. Enhancements are classified by contributors * Does it indeed solve the problems? * How is the complexity? Is it feasible? 6. The enhancement can be iterated or an enhanced enhancement proposed :) 7. Enhancements get classified gains. 8. Contributors are encouraged to pick enhancements with high gain. New contributors are encouraged to additionally filter for low complexity. 9. Pull requests need to reference either an accepted enhancement OR a trivial problem ("bug" in step 3.1) * It is important that the workflow does not reduce productivity for obvious cases like regressions or simple bugs. * However, fast-tracking should only be done for few and small changes. 10. Problems can be closed if Forgejo contributors do not plan to actively look for a solution to clear the backlog. However, closed problems are still valid user experience reports and can still allow to justify an enhancement, as long as an enhancement does not only address closed problems. * It is not valid to propose an enhancement to address a problem that was considered low severity. * However, it is valid to propose an enhancement that, among others, also improves the situation for a problem that was previously ignored. ### Which problems does this solve? * Since Problems are the required first step, we get rid of feature requests and pull requests that serve no clear value * Currently, taking a step back and asking about the actual problem behind an idea requires "someone to be the bad guy", e.g. https://codeberg.org/forgejo/forgejo/issues/157#issuecomment-8199287 or https://codeberg.org/forgejo/forgejo/pulls/10007#issuecomment-8165240 * Going forward, new contributors can simply be hinted towards a defined workflow and asked to complete the required steps to justify their idea or patch * The workflow focuses on having a clear workflow that **every** Forgejo contributor can follow and does not create a user-research bottleneck. * All contributors get a better understanding of how the design work should be conducted. * There is less confusion about "bugs" vs "feature requests" in some cases. The focus is on demonstrating that a change is worth the effort. * I feel like this is particularly important and addresses the "an existing behavior that is demonstrated to be confusing for users is considered to be a bug" from https://codeberg.org/forgejo/discussions/issues/337# * A small quality of life fix is equally suited as a first contribution, important is the confirmed gain and the complexity * Problems that are not severe enough to deserve a fix (e.g. "cannot integrate Forgejo with third-party platform xyz" or "I would like to schedule a meeting with Forgejo contributors") can get discarded earlier, before too much discussion went into the solution and technical details ("I need a calendar and an appointment feature") * Problems serve as an archive. Contrary to rejecting a feature request, closing a problem can still convey it as being acknowledged. Future enhancements can still refer to the first hand user experience of closed problems to justify the relevance. * Some requests, especially highly technical needs, are sometimes hard to be judged by the user research team, because it requires significant understanding of a certain domain (for example, I sometimes struggle to perform reasonable user research in the domain of CI/CD integrations) ### How to get there? 1. The issue templates are being reworked. 2. Labels are created to allow classifying problems for the severity and enhancements for the complexity. * The `gain/*` labels could be kept for the enhancements. * New `severity/*` labels are introduced for problems. * New `complexity/*` labels are created. * The good first issue label could be renamed into `complexity/easy-starter` (or similar); or it could be kept additionally to not only mark simple fixes but ones that are good learning opportunities. 3. Existing feature requests (~800) are triaged. * If they seem valuable and clear, existing feature requests get relabeled as an enhancement with no further adjustments. * If they seem valuable and can be clarified, a new enhancement is created referencing the previous feature request, and the old feature request is marked a problem * If they seem valuable but not clear, the issue remains open and the author is asked to clarify the problem using the new template. * Otherwise, the issue is closed and the author also asked to clarify the problem using the new template. 4. My goal would be to classify 100 issues, then consider adjustments to the workflow (e.g. if some issue was still unclear on how to proceed); then proceed with the other backlog of issues over the next 6 months 5. I am *not yet* sure how to proceed with the ~250 bug reports ### Open questions * Should everything be done in the forgejo/forgejo repository? * I think it would be good enough with the use of labels and would avoid the need to tell people about the additional repositories. * What about forgejo/design? * I think I would prefer to move the discussions happening there back into the main issue tracker. It was a nice experiment, and now that contributors have picked it up, I feel like it's time to move the discussions where everyone can easily find them. * Who does the work? * Well, as indicated in https://codeberg.org/forgejo/discussions/issues/178, I'm very motivated to do a huge chunk of work related to this, including the preparation (labels + issue templates) and sorting the backlog (in many cases copy-pasting the same text and quickly deciding whether the issue gets closed or not) * I feel like the approach is good for distributing the work and reducing bottlenecks. Going forward, the work can be handled by everyone, even contributors with little free time. * What about bug reports? * Since my proposal will still have the bug labels, I think it's fine to keep them untouched at first. * They can still be classified later (maybe some bugs are rather problems and it is not yet clear if and how they should be fixed, but I think it is not urgent to do this work) --- I'm looking forward to hearing your opinions. I'm very happy to refine the proposal, but I'd like to finally reach a conclusion. I have spent a lot of time thinking about this during the summer months and I hope the revised proposal will soon become a reality. Thank you!

I like the proposed approach.

It seems like a daily ritual right now to find an issue submitted without a clear description of a problem, and containing just a proposed solution. If a contributor's interest doesn't extend into implementation, their primary input into this system would be describing their problems which feels direct and useful, which is just the core information that is needed.

There might be value in having two different types of problems. A "technical problem" would have template fields for things like the user's Forgejo version, database version, notes about attaching logs. A "user problem" (?) would omit those fields and maybe just describe what the user wants to do, why they can't do it, and how they workaround the absence of the capability today. On the other hand, every addition of complexity in a new process should be rigorously questioned. 🙂

While I'm very skeptical of LLM technologies, I wonder if you've considered their applicability to your "How to get there?". I think your current plan has an important benefit in learning how well the classification system works by performing the classification as a human being, and adapting the system based upon your learning. After the details are worked out (and presumably documented), this problem of classifying issue reports would be right up an LLM alley -- text classification according to written rules, no life-or-death consequences to mistakes, and a large number of issues to work through.

Should everything be done in the forgejo/forgejo repository?

sigh Probably. Something about an endless list of issues in one repo makes me feel anxious, but I think there's benefits to keeping it in one space.

I like the proposed approach. It seems like a daily ritual right now to find an issue submitted without a clear description of a problem, and containing just a proposed solution. If a contributor's interest doesn't extend into implementation, their primary input into this system would be describing their problems which feels direct and useful, which is just the core information that is needed. There might be value in having two different types of problems. A "technical problem" would have template fields for things like the user's Forgejo version, database version, notes about attaching logs. A "user problem" (?) would omit those fields and maybe just describe what the user wants to do, why they can't do it, and how they workaround the absence of the capability today. On the other hand, every addition of complexity in a new process should be rigorously questioned. 🙂 While I'm very skeptical of LLM technologies, I wonder if you've considered their applicability to your "How to get there?". I think your current plan has an important benefit in learning how well the classification system works by performing the classification as a human being, and adapting the system based upon your learning. After the details are worked out (and presumably documented), this problem of classifying issue reports would be right up an LLM alley -- text classification according to written rules, no life-or-death consequences to mistakes, and a large number of issues to work through. > Should everything be done in the forgejo/forgejo repository? **sigh** Probably. Something about an endless list of issues in one repo makes me feel anxious, but I think there's benefits to keeping it in one space.
Author
Owner
Copy link

Hmm, I feel like the current different templates for reporting bugs are already causing confusion. What is a frontend and what a backend bug. If a button does not work, is the browser version relevant or is only the API call to the backend failing?

forgejo/forgejo#9978 is a recent example where I struggled myself. I picked the frontend template, because I considered a broken template to be a frontend bug, but then got confused that I was asked for screenshots and a browser version.

My proposed solution would go into reworking the issue template in a way that nudges users into providing such detail unless they know it is not relevant.

Hmm, I feel like the current different templates for reporting bugs are already causing confusion. What is a frontend and what a backend bug. If a button does not work, is the browser version relevant or is only the API call to the backend failing? https://codeberg.org/forgejo/forgejo/issues/9978 is a recent example where I struggled myself. I picked the frontend template, because I considered a broken template to be a frontend bug, but then got confused that I was asked for screenshots and a browser version. My proposed solution would go into reworking the issue template in a way that nudges users into providing such detail unless they know it is not relevant.

The proposed workflow sounds pretty good; but I am a little bit scared when thinking about everything happening in the same forgejo/forgejo repository, especially when one watches the repository (I personally find overwhelming the current amount of daily notifications and would rather appreciate if things like cascading PRs or dependency updates could be moved elsewhere). In the same time, working with multiple repositories might make things harder (e.g. when it cames to searching or cross-referencing).

I feel like the current different templates for reporting bugs are already causing confusion.

Agree. Some issues might affect both the backend and the frontend or one might not have enough info to decide if it's one or the other.

The proposed workflow sounds pretty good; but I am a little bit scared when thinking about everything happening in the same forgejo/forgejo repository, especially when one watches the repository (I personally find overwhelming the current amount of daily notifications and would rather appreciate if things like cascading PRs or dependency updates could be moved elsewhere). In the same time, working with multiple repositories might make things harder (e.g. when it cames to searching or cross-referencing). --- > I feel like the current different templates for reporting bugs are already causing confusion. Agree. Some issues might affect both the backend and the frontend or one might not have enough info to decide if it's one or the other.
Author
Owner
Copy link

There is one aspect that I forgot to mention (added to the first comment now). I sometimes struggle to do user research in problem spaces that I'm not very familiar with. It's trivial to judge how features should work when I can relate to the problems of users easily. However, Forgejo also addresses a highly technical user base, and understanding the exact needs when it comes to complex CI/CD setups, as well as feature requests that are only of technical nature (e.g. code optimizations) is very hard. Effectively, these feature requests often don't get triaged at all. Distributing the judgement to more people will also bring knowledge of other domains into play.

@floss4good TBH, I think that no one should be watching a whole repository. It is too much, no matter what. I don't think that my proposal increases the noise in forgejo/forgejo. It just structures it differently. However, if many people feel like the noise is too much, it would be a chance to split things up. For example, users could report Problems to forgejo/forgejo, and Enhancements are tracked in a dedicated issue tracker so that developers can focus on actionable items.

There is one aspect that I forgot to mention (added to the first comment now). I sometimes struggle to do user research in problem spaces that I'm not very familiar with. It's trivial to judge how features should work when I can relate to the problems of users easily. However, Forgejo also addresses a highly technical user base, and understanding the exact needs when it comes to complex CI/CD setups, as well as feature requests that are only of technical nature (e.g. code optimizations) is very hard. Effectively, these feature requests often don't get triaged at all. Distributing the judgement to more people will also bring knowledge of other domains into play. @floss4good TBH, I think that no one should be watching a whole repository. It is too much, no matter what. I don't think that my proposal increases the noise in forgejo/forgejo. It just structures it differently. However, if many people feel like the noise is too much, it would be a chance to split things up. For example, users could report Problems to forgejo/forgejo, and Enhancements are tracked in a dedicated issue tracker so that developers can focus on actionable items.
Author
Owner
Copy link

I have created a draft for the new issue templates in forgejo/forgejo#10054, I hope it helps you to get a good understanding of how the templates should look like.

I have created a draft for the new issue templates in https://codeberg.org/forgejo/forgejo/pulls/10054, I hope it helps you to get a good understanding of how the templates should look like.

This proposal looks sensible.
In addition to an issue template, I think a "pinned issue" would be quite helpful as well. Something like the following: (the labels must be adjusted)

The goal is for anyone looking at the issue tracker to easily filter the issues, when looking for something to do (as well as being an easy-to-link reference).

I split problems in "confirmed/straightforward", since issues like forgejo/forgejo#9881 can directly be addressed without an enhancement (such "straightforward" problems can be "good first issue").

Since late 2025, we are experimenting with a new workflow to understand your problems and requests. The goal is to discuss potential solutions to already-reported problems. If you want to learn more about the background of our workflow, feel invited to read and participate in the discussion that lead to the current approach. We are looking forward to your feedback.

First step, documenting problems:

  • New Problems: recently reported problems, which need some investigation
  • Confirmed Problems: confirmed problems (closed issue can still be considered, but have lower priority). An enhancement can be proposed (see below).
  • Straightforward Problems: confirmed problem, for which a solution is straightforward (simple bugs usually land here).
  • Solved Problems: problems which have been solved via an enhancement (see below)

Second step, proposing enhancement:

This proposal looks sensible. In addition to an issue template, I think a "pinned issue" would be quite helpful as well. Something like the following: (the `labels` must be adjusted) The goal is for anyone looking at the issue tracker to easily filter the issues, when looking for something to do (as well as being an easy-to-link reference). I split problems in "confirmed/straightforward", since issues like forgejo/forgejo#9881 can directly be addressed without an enhancement (such "straightforward" problems can be "good first issue"). --- _Since late 2025, we are experimenting with a new workflow to understand your problems and requests. The goal is to discuss potential solutions to already-reported problems. If you want to learn more about the background of our workflow, feel invited to read and participate in [the discussion that lead to the current approach](https://codeberg.org/forgejo/discussions/issues/415). We are looking forward to your feedback._ First step, documenting problems: - [New Problems](https://codeberg.org/forgejo/forgejo/issues?labels=201022&state=open): recently reported problems, which need some investigation - [Confirmed Problems](https://codeberg.org/forgejo/forgejo/issues?labels=201022&state=all): confirmed problems (closed issue can still be considered, but have lower priority). An enhancement can be proposed (see below). - [Straightforward Problems](https://codeberg.org/forgejo/forgejo/issues?labels=201022&state=open): confirmed problem, for which a solution is straightforward (simple bugs usually land here). - [Solved Problems](https://codeberg.org/forgejo/forgejo/issues?labels=201022&state=all): problems which have been solved via an enhancement (see below) Second step, proposing enhancement: - [Proposed Enhancements](https://codeberg.org/forgejo/forgejo/issues?labels=201022&state=open): recently proposed enhancement, which need some investigation - [Accepted Enhancements](https://codeberg.org/forgejo/forgejo/issues?labels=201022&state=all): accepted enhancement (open/closed depending on PR merge status)
Author
Owner
Copy link

@oliverpool Do you imagine that "solved" problems get an additional label? While I like the idea of recording whether a problem was closed because it was not considered important enough, or because it really no longer exists, I fear that this requires more effort to set the labels.

Technically, it would be possible to automate: If enhancements record which problems they solve, a workflow could be triggered on closed enhancements to also label related problems.

@oliverpool Do you imagine that "solved" problems get an additional label? While I like the idea of recording whether a problem was closed because it was not considered important enough, or because it really no longer exists, I fear that this requires more effort to set the labels. Technically, it would be possible to automate: If enhancements record which problems they solve, a workflow could be triggered on closed enhancements to also label related problems.

Problems can be closed if Forgejo contributors do not plan to actively look for a solution to clear the backlog. However, closed problems are still valid user experience reports and can still allow to justify an enhancement, as long as an enhancement does not only address closed problems.

How can we distinguished between "closed because of lack of activity" vs "closed because solved"?

> Problems can be closed if Forgejo contributors do not plan to actively look for a solution to clear the backlog. However, closed problems are still valid user experience reports and can still allow to justify an enhancement, as long as an enhancement does not only address closed problems. How can we distinguished between "closed because of lack of activity" vs "closed because solved"?
Author
Owner
Copy link

BTW, during yesterday's user research session, I encountered an interesting case that I would not really know whether it should be labeled bug or feature request.

  • You have a repo with a default branch and two additional branches (A, B)
  • There is an existing pull request between from B to A
  • You push to branch B
  • Forgejo suggests to create a PR from B to main, but the user expects to view the "Visit existing PR for this branch" to visit the PR from B to A

The case is interesting, because it demonstrates how splitting problems from solutions can bring benefits. For this specific problem, even if it is considered a "bug", the fix is not clear. There are two possibilities:

  • If a PR for the branch exists, Forgejo always sends the link to it and does not suggest creating a new PR.
  • If a PR for the branch exists, Forgejo sends the link to it and additionally suggests creating a new one to the default branch.
BTW, during yesterday's user research session, I encountered an interesting case that I would not really know whether it should be labeled bug or feature request. * You have a repo with a default branch and two additional branches (A, B) * There is an existing pull request between from B to A * You push to branch B * Forgejo suggests to create a PR from B to main, but the user expects to view the "Visit existing PR for this branch" to visit the PR from B to A The case is interesting, because it demonstrates how splitting problems from solutions can bring benefits. For this specific problem, even if it is considered a "bug", the fix is not clear. There are two possibilities: * If a PR for the branch exists, Forgejo always sends the link to it and does not suggest creating a new PR. * If a PR for the branch exists, Forgejo sends the link to it and *additionally* suggests creating a new one to the default branch.
Author
Owner
Copy link

How can we distinguished between "closed because of lack of activity" vs "closed because solved"?

I'd imagine that we never close problems just because they lack activity. I think labels would be the only way to tell them apart, so we either need to label resolved problems or unresolved ones. No special preference.

Again, if the workflow is decided, there could be automation. Assuming there would be a standard message explaining the reporter why an issue is closed, Forgejo contributors could just set the label and have an action fire the corresponding close + message.

> How can we distinguished between "closed because of lack of activity" vs "closed because solved"? I'd imagine that we never close problems just because they lack activity. I think labels would be the only way to tell them apart, so we either need to label resolved problems or unresolved ones. No special preference. Again, if the workflow is decided, there could be automation. Assuming there would be a standard message explaining the reporter why an issue is closed, Forgejo contributors could just set the label and have an action fire the corresponding close + message.

I like your proposal: A similar approach to issues is used in the Ghostty project. There, two trackers are used: discussions for all things you call "problems" and issues for "actionable items" and real bugs. I can imagine that this separation helps.

I like your proposal: A similar approach to issues is used in the [Ghostty project](https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md). There, two trackers are used: discussions for all things you call "problems" and issues for "actionable items" and real bugs. I can imagine that this separation helps.
Author
Owner
Copy link

Thank you for sharing this. Some notes for our inspiration:

  • I like the pinned issue, as also proposed in the thread here
  • I appreciate the "Not sure what information to include? Here are some recommendations:" for bug reports and will likely adjust my template draft accordingly
  • I don't really think that the separation in different places is necessary. I believe that labels would be good enough, but
  • maybe explicit state labels like "understanding", "finding solutions" towards "actionable" / "implementation" etc make sense.
Thank you for sharing this. Some notes for our inspiration: * I like the pinned issue, as also proposed in the thread here * I appreciate the "Not sure what information to include? Here are some recommendations:" for bug reports and will likely adjust my template draft accordingly * I don't really think that the separation in different places is necessary. I believe that labels would be good enough, but * maybe explicit state labels like "understanding", "finding solutions" towards "actionable" / "implementation" etc make sense.

How would gain, severity, and complexity be assessed and expressed?

Contributors are encouraged to pick enhancements with high gain. New contributors are encouraged to additionally filter for low complexity.

People are most motivated when they can work on problems that affect them or that they care about. Why not just let them work on them, as long as it doesn't inconvenience the project too much?

I believe it's important to only have positive messages so as not to scare people away. It should be okay to have markers that signal "Hey, fixing this issue helps a lot of people". But it's bad to have markers that indicate "Nobody cares about that. Don't even dare to send a PR." Similarly, encouraging people not to work on "low gain" issues leads to a death by one thousand cuts.

Many old issues with high gain or severity may be a bad look, too.

How would gain, severity, and complexity be assessed and expressed? > Contributors are encouraged to pick enhancements with high gain. New contributors are encouraged to additionally filter for low complexity. People are most motivated when they can work on problems that affect them or that they care about. Why not just let them work on them, as long as it doesn't inconvenience the project too much? I believe it's important to only have positive messages so as not to scare people away. It should be okay to have markers that signal "Hey, fixing this issue helps a lot of people". But it's bad to have markers that indicate "Nobody cares about that. Don't even dare to send a PR." Similarly, encouraging people not to work on "low gain" issues leads to a death by one thousand cuts. Many old issues with high gain or severity may be a bad look, too.

I think the gain should mainly influence the acceptable complexity of the related PR.

A low gain which requires migrations and changes all over the codebase has higher chances of not being reviewed/merged.
Similar changes for a „high gain" might be acceptable.

Many old issues with high gain or severity may be a bad look, too.

This is a community project. If people really want something, then they should look how to get it done and not expect that someone will do it for them.

I think the gain should mainly influence the acceptable complexity of the related PR. A low gain which requires migrations and changes all over the codebase has higher chances of not being reviewed/merged. Similar changes for a „high gain" might be acceptable. > Many old issues with high gain or severity may be a bad look, too. This is a community project. If people really want something, then they should look how to get it done and not expect that someone will do it for them.
Author
Owner
Copy link

@aahlenst I think you are starting an off-topic discussion. Although potentially valuable, I ask you to move it to a separate discussion if you care about it. The problems you mention are not specific to my proposal. The Gain labels are already in used, and we are already encouraging new contributors to pick bug fixes.

@aahlenst I think you are starting an off-topic discussion. Although potentially valuable, I ask you to move it to a separate discussion if you care about it. The problems you mention are not specific to my proposal. The Gain labels are already in used, and we are already encouraging new contributors to pick bug fixes.

Another example where something similar is practiced is the Forgejo runner within the Forgejo community. When creating a new feature request you are advised to follow

A dedicated repository contains these new ideas.

@earl-warren What is your experience with that? And maybe do you have / or do you want to share thoughts on this proposal?

Another example where something similar is practiced is the Forgejo runner within the Forgejo community. When [creating a new feature request](https://code.forgejo.org/forgejo/runner/issues/new?template=.forgejo%2fissue_template%2ffeature-request.yaml) you are advised to follow > - New ideas must be [proposed in an issue tracker dedicated to feature requests](https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/new?template=.forgejo%2fissue_template%2ffeature-request.yaml). > - Ideas that have been prepared there and are ready to be implemented can be proposed here. A dedicated repository contains these [new ideas](https://code.forgejo.org/forgejo/forgejo-actions-feature-requests). @earl-warren What is your experience with that? And maybe do you have / or do you want to share thoughts on this proposal?
Author
Owner
Copy link

Given there was no further feedback, I would like to move ahead. The next steps, IMHO are:

  • review forgejo/forgejo#10054
  • create the "impact" labels for problems
  • merge the PR and observe how new reports come in using the new templates and learn from user feedback
Given there was no further feedback, I would like to move ahead. The next steps, IMHO are: * review https://codeberg.org/forgejo/forgejo/pulls/10054 * create the "impact" labels for problems * merge the PR and observe how new reports come in using the new templates and learn from user feedback

Threw my current model of the proposed workflow into a diagram (source here), is this accurate?

Threw my current model of the proposed workflow into a diagram ([source here](https://codeberg.org/MultisampledNight/diagram/src/commit/374d7f2bd6d4b9e5be8a2991bd73754a695a39f3/source/forgejo-issue-workflow/main.typ)), is this accurate?
Author
Owner
Copy link

Somewhat. I'm not sure about the "needs-design" part. What does this mean?

Somewhat. I'm not sure about the "needs-design" part. What does this mean?
Author
Owner
Copy link

I used the new workflow myself and reported two problems, then suggested a solution in forgejo/forgejo#10499. In this case, I fast-tracked this, because I must admit that I thought about the solution in the moment I learned about the problem (one of the last user research sessions).

I think it is a nice demonstration how one enhancement proposal can focus on the implementation aspects (a contributor only needs to think about the "What to change", not about the exact motivation, which was explained in another step), and the change actually resolves two related problems, without the need to touch the related code twice.

I also ran into confusing behaviour while creating the issues which I documented in forgejo/forgejo#10498, and I really appreciated that I was able to focus on my experience rather than classifying whether this is a bug or a feature request, and which solution I want to make. The problem I reported can be resolved via different ways (making the headers stick all the time, making the rest of the page scroll up to make room for the heading or maybe other things I didn't yet think about), but this step can be deferred to later.

As a contributor, when I labeled the first problem in forgejo/forgejo#10496, I was hesitant about which label to choose. I chose "impact/small", because I think the problem is quite a small one. However, although small, it potentially affects many users. It might be useful to split up the severity from the affected users and choose something like "small impact, many users affected" or "large impact, few users affected". What do you think?

I used the new workflow myself and reported two problems, then suggested a solution in https://codeberg.org/forgejo/forgejo/issues/10499. In this case, I fast-tracked this, because I must admit that I thought about the solution in the moment I learned about the problem (one of the last user research sessions). I think it is a nice demonstration how one enhancement proposal can focus on the implementation aspects (a contributor only needs to think about the "What to change", not about the exact motivation, which was explained in another step), and the change actually resolves two related problems, without the need to touch the related code twice. I also ran into confusing behaviour while creating the issues which I documented in https://codeberg.org/forgejo/forgejo/issues/10498, and I really appreciated that I was able to focus on my experience rather than classifying whether this is a bug or a feature request, and which solution I want to make. The problem I reported can be resolved via different ways (making the headers stick all the time, making the rest of the page scroll up to make room for the heading or maybe other things I didn't yet think about), but this step can be deferred to later. As a contributor, when I labeled the first problem in https://codeberg.org/forgejo/forgejo/issues/10496, I was hesitant about which label to choose. I chose "impact/small", because I think the problem is quite a small one. However, although small, it potentially affects many users. It might be useful to split up the severity from the affected users and choose something like "small impact, many users affected" or "large impact, few users affected". What do you think?

@fnetX wrote in #415 (comment):

As a contributor, when I labeled the first problem in forgejo/forgejo#10496, I was hesitant about which label to choose. I chose "impact/small", because I think the problem is quite a small one. However, although small, it potentially affects many users. It might be useful to split up the severity from the affected users and choose something like "small impact, many users affected" or "large impact, few users affected". What do you think?

I think the split is worth considering, given that the current state of affairs in this area is upvoting or downvoting via emoji reaction, which I don't think would be necessarily representative of how many users are affected.

That being said, maybe we should add a suggestion to the template to say that if the bug/feature affects you, comment with details regarding your setup. If the number of users who comment passes a certain number (e.g. 10 users affected), then we can say the issue is small but affecting many users. If the bug causes serious to semi-serious issues (say data loss or requires more expertise than is expected of the average Forgejo admin/user to find a workaround), then we can say large impact, few users affected.

Apart from that I look forward to interacting with the workflow :)

@fnetX wrote in https://codeberg.org/forgejo/discussions/issues/415#issuecomment-9089793: > As a contributor, when I labeled the first problem in forgejo/forgejo#10496, I was hesitant about which label to choose. I chose "impact/small", because I think the problem is quite a small one. However, although small, it potentially affects many users. It might be useful to split up the severity from the affected users and choose something like "small impact, many users affected" or "large impact, few users affected". What do you think? I think the split is worth considering, given that the current state of affairs in this area is upvoting or downvoting via emoji reaction, which I don't think would be necessarily representative of how many users are affected. That being said, maybe we should add a suggestion to the template to say that if the bug/feature affects you, comment with details regarding your setup. If the number of users who comment passes a certain number (e.g. 10 users affected), then we can say the issue is small but affecting many users. If the bug causes serious to semi-serious issues (say data loss or requires more expertise than is expected of the average Forgejo admin/user to find a workaround), then we can say large impact, few users affected. Apart from that I look forward to interacting with the workflow :)
Author
Owner
Copy link

I'll try to rework the labels accordingly.

In the past days, more problems have been reported, and I'm still looking forward to receiving more feedback from contributors. Personally, I feel like issues are mostly in two states: They require technical debugging to investigate the problem, or they require UX input about how to proceed. It might be useful to discriminate between the two.

I'll try to rework the labels accordingly. In the past days, more problems have been reported, and I'm still looking forward to receiving more feedback from contributors. Personally, I feel like issues are mostly in two states: They require technical debugging to investigate the problem, or they require UX input about how to proceed. It might be useful to discriminate between the two.

BTW, there seems to be an issue with the impact/ labels (or a bug?!): even though they are Exclusive labels, somehow it was possible to add both impact/small and impact/medium on the same issue.

BTW, there seems to be an issue with the `impact/` labels (or a bug?!): even though they are _Exclusive_ labels, somehow it was possible to add both `impact/small` and `impact/medium` [on the same issue](https://codeberg.org/forgejo/forgejo/issues/10565#issuecomment-9298322).

I linked to this discussion recently to point a contributor in the direction of problems/enhancements as described here. In doing so I wondered, is there a plan to document the updated approach somewhere that doesn't call it a "proposal", but instead calls it "here's how the issue tracker works" (or similar)?

I linked to this discussion recently to point a contributor in the direction of problems/enhancements as described here. In doing so I wondered, is there a plan to document the updated approach somewhere that doesn't call it a "proposal", but instead calls it "here's how the issue tracker works" (or similar)?

Hello. I tried to submit a feature request for Forgejo. The issue forms mentioned that you are looking for feedback, therefore I will leave feedback here.

This was likely the worst experience I had reporting an issue to a libre project so far, and I have reported issues for quite a few projects.

For something as simple as:

Add a way to enable displaying the e-mail address field on the profile to logged out users.

This could be done by providing a dropdown list of choices for "E-mail address visibility": "Private", "Only logged in users" and "Public".

I had to write an essay split across two issues (forgejo/forgejo#10711 and forgejo/forgejo#10712), because I cannot say that this can be implemented with a dropdown list without making a separate "enhancement" issue. Imagine if I had an alternative proposed solution, that would require splitting the essay across three issues!

This is not effective communication. This is how computers communicate, not people.

If you want to give your users the best experience, please just provide a form for a "feature request". There is already a form for a "bug report" that doesn't require this crazy "problem"/"enhancement" workflow.

I'm sorry if this is rude, but I really hated doing this and it drove me insane how long it took me to suggest a simple feature. That last part might be a "me" issue though.

Hello. I tried to submit a feature request for Forgejo. The issue forms mentioned that you are looking for feedback, therefore I will leave feedback here. This was likely the worst experience I had reporting an issue to a libre project so far, and I have reported issues for quite a few projects. For something as simple as: > Add a way to enable displaying the e-mail address field on the profile to logged out users. > > This could be done by providing a dropdown list of choices for "E-mail address visibility": "Private", "Only logged in users" and "Public". I had to write *an essay* split across two issues (https://codeberg.org/forgejo/forgejo/issues/10711 and https://codeberg.org/forgejo/forgejo/issues/10712), because I cannot say that this can be implemented with a dropdown list without making a separate "enhancement" issue. Imagine if I had an alternative proposed solution, that would require splitting the essay across *three* issues! This is not effective communication. This is how computers communicate, not people. If you want to give your users the best experience, please just provide a form for a "feature request". There is already a form for a "bug report" that doesn't require this crazy "problem"/"enhancement" workflow. I'm sorry if this is rude, but I really hated doing this and it drove me insane how long it took me to suggest a simple feature. That last part might be a "me" issue though.
Author
Owner
Copy link

@Grzesiek11 Thank you for your honest feedback. Please note that for something like this, you are not required to suggest how we implement it. We can think about this on our own.

However, it is important to understand why you need it, because we obviously cannot implement all the suggestions we receive. To me, forgejo/forgejo#10711 would be enough. It explains the problem you are facing and some background information. What would be even more helpful is understanding why you want the email to the public (e.g. just as a nice to have, or because you intend to receive patches to this address etc). It also helps to judge how important this is to other users.

I understand that this is time-consuming. However, explaining your situation properly within 5 minutes is much less effort compared to implementing hundreds of features and buttons that might only benefit a few users. Please consider the time you need to understand software, read the docs, find things in menus. It also adds up to hours. We aim to save users's time by making Forgejo intuitive and accessible, and not a mess of options that only benefit a single user.

@Grzesiek11 Thank you for your honest feedback. Please note that for something like this, you are not required to suggest *how* we implement it. We can think about this on our own. However, it is important to understand *why* you need it, because we obviously cannot implement all the suggestions we receive. To me, https://codeberg.org/forgejo/forgejo/issues/10711 would be enough. It explains the problem you are facing and some background information. What would be even more helpful is understanding why you want the email to the public (e.g. just as a nice to have, or because you intend to receive patches to this address etc). It also helps to judge how important this is to other users. I understand that this is time-consuming. However, explaining your situation properly within 5 minutes is much less effort compared to implementing hundreds of features and buttons that might only benefit a few users. Please consider the time you need to understand software, read the docs, find things in menus. It also adds up to hours. We aim to save users's time by making Forgejo intuitive and accessible, and not a mess of options that only benefit a single user.

I'd like to echo @Grzesiek11 sentiments. While the new issue templates are an improvement, filing issues is painful across Forgejo. I no longer file issues if I can somehow avoid it. The templates are too rigid (thereby encouraging low quality submissions in some cases), ask for too many things, and they feel like a hoop that I have to jump through and not as a helpful tool that I can use but don't have to. And if I file the issue in the wrong repo, hoo boy!

I'd like to echo @Grzesiek11 sentiments. While the new issue templates are an improvement, filing issues is painful across Forgejo. I no longer file issues if I can somehow avoid it. The templates are too rigid (thereby encouraging low quality submissions in some cases), ask for too many things, and they feel like a hoop that I have to jump through and not as a helpful tool that I can use but don't have to. And if I file the issue in the wrong repo, hoo boy!

To me forgejo/forgejo#10712 is more useful than forgejo/forgejo#10711, for the most reason because it doesn't try to classify it like a bug but as a enhancement - there's nothing broken. Given #337 I would like to keep that distinction very clear.

The potential workaround is nice to have, but also feels like suggesting people that "ah you have a workaround so less important".

To me forgejo/forgejo#10712 is more useful than forgejo/forgejo#10711, for the most reason because it doesn't try to classify it like a bug but as a enhancement - there's nothing broken. Given https://codeberg.org/forgejo/discussions/issues/337 I would like to keep that distinction very clear. The potential workaround is nice to have, but also feels like suggesting people that "ah you have a workaround so less important".

Hi, would you mind remove this? You can retain the rest which is a good notice.

2026年01月06日_20-19

When it comes to technical problem: a verbose report is often required for the fixer to analyze; not just for triage. On security matter, this is extremely vital as a discoverer has to go through extra steps to make sure the vulnerability is exactly as reported since CVE filing is involved and multiple parties are notified (same dataset is disclosed to every parties for reproducability).

Please understand that if I receive an acknowledgement (before confirmation) from the security team after the email is sent successfully, I would not file a public disclosure issue (that you guys deleted) for that CVE on Codeberg the next day. Right now, it is still confidential as part of the responsible disclosure. If there is a "Security Advisory" feature, I would definitely file that. I already spoken my part for: forgejo/forgejo#4944

Just my few cent. Sorry for causing a hiccups. Cheers & Happy New Year.

UPDATE

Side-notes: Please ping my username if you are replying any content of this post. I rarely login Codeberg (only for Forgejo).

Hi, would you mind remove this? You can retain the rest which is a good notice. ![2026年01月06日_20-19](/attachments/b100cb5e-f31d-466b-aa6d-96bdfa9919f6) When it comes to technical problem: a verbose report is often required for the fixer to analyze; not just for triage. On security matter, this is extremely vital as a discoverer has to go through extra steps to make sure the vulnerability is exactly as reported since CVE filing is involved and multiple parties are notified (same dataset is disclosed to every parties for reproducability). Please understand that if I receive an acknowledgement (before confirmation) from the security team after the email is sent successfully, I would not file a public disclosure issue (that you guys deleted) for that CVE on Codeberg the next day. Right now, it is still confidential as part of the responsible disclosure. If there is a "Security Advisory" feature, I would definitely file that. I already spoken my part for: https://codeberg.org/forgejo/forgejo/issues/4944 Just my few cent. Sorry for causing a hiccups. Cheers & Happy New Year. ---- UPDATE Side-notes: Please ping my username if you are replying any content of this post. I rarely login Codeberg (only for Forgejo).
Author
Owner
Copy link

To me forgejo/forgejo#10712 is more useful than forgejo/forgejo#10711

I'd like to understand why you prefer the other issue. How does the former help you understand why the feature is needed and how relevant it is to the user? How would you proceed in triaging it's importance and defining the priority in the Forgejo backlog from that alone?

> To me forgejo/forgejo#10712 is more useful than forgejo/forgejo#10711 I'd like to understand why you prefer the other issue. How does the former help you understand why the feature is needed and how relevant it is to the user? How would you proceed in triaging it's importance and defining the priority in the Forgejo backlog from that alone?

@fnetX wrote in #415 (comment):

I'd like to understand why you prefer the other issue

It's cut and clear and in this case I am personally not that interested in the whole back story. It would make sense on another feature requests where the gain is genuinely hard to find or justify because it's harder for someone to explain what they want.

@fnetX wrote in #415 (comment):

How would you proceed in triaging it's importance and defining the priority in the Forgejo backlog from that alone?

I can't triage the problem workflow anyway now because there's no "bug confirmed" just a impact label which requires even more looking into the issue (or feature) to determine that and having a slightly hard time wrapping my mind how this should be used on requests of enhancements and on genuine bugs in the code.

@fnetX wrote in https://codeberg.org/forgejo/discussions/issues/415#issuecomment-9598157: > I'd like to understand why you prefer the other issue It's cut and clear and in this case I am personally not that interested in the whole back story. It would make sense on another feature requests where the gain is genuinely hard to find or justify because it's harder for someone to explain what they want. @fnetX wrote in https://codeberg.org/forgejo/discussions/issues/415#issuecomment-9598157: > How would you proceed in triaging it's importance and defining the priority in the Forgejo backlog from that alone? I can't triage the problem workflow anyway now because there's no "bug confirmed" just a impact label which requires even more looking into the issue (or feature) to determine that and having a slightly hard time wrapping my mind how this should be used on requests of enhancements and on genuine bugs in the code.
Author
Owner
Copy link

I have tried to collect feedback outside of this thread so that raw data can be separate from discussion and conclusions. forgejo/user-research#71

Further research is currently blocked by an iteration of the templates that is awaiting review in forgejo/forgejo#10847. After it is merged, the authors of newer issues can be asked about their experience again.

I have tried to collect feedback outside of this thread so that raw data can be separate from discussion and conclusions. https://codeberg.org/forgejo/user-research/issues/71 Further research is currently blocked by an iteration of the templates that is awaiting review in https://codeberg.org/forgejo/forgejo/pulls/10847. After it is merged, the authors of newer issues can be asked about their experience again.
Author
Owner
Copy link

Hi everyone! During FOSDEM, some things have moved quite quickly, and I only now find the time to hit you up here.

We had a small meetup with @mfenniak, @famfo, @Gusted, @n0toose and @wetneb on Saturday and discussed things. There are no real minutes, but I'll share some things from the top of my head. The most important thing is that we discussed an idea on reorganizing the issue workflow so that it will work better.

I gave a talk about this very topic on Sunday, and also talked about the idea we had, so the changes I intend to make are kinda communicated to the public before being discussed here. I apologize for the rush, but assume that given the approval of several people during FOSDEM, this will be fine overall. I will try to go ahead with applying the changes.

One request for everyone involved: I really appreciate feedback, and lack of feedback is what slowed down the iteration. So if you have something to share or to complain about, please bring it up here or in the user research issue.

The things discussed during the meeting were basically:

  • For many issues, it is not clear for which group they are actionable (does it need user research input, or someone with technical skills to take a look?)
  • Why the workflow is confusing to users
    • likely due to the nature of having to choose between types
    • problem as a name for template and label still feels weird if you rather have a need (although it also says that you can describe a need)
  • Stages are likely clearer to understand and follow
  • fast-tracking is important, so marking trivial bugs as ready for implementation quickly is important
  • finding issues that are suggested to work on is difficult, because you might want to check all 3 gain labels (high, very high, nice to have)
    • filtering for "implentation" stage issues is easier, the gain labels can serve as an additional indication for priorities

The changes I want to apply precisely are:

  • rename the "problem" label to "stage/1-triaging"
  • introduce scoped labels:
    • stage/2-research
    • stage/3-design
    • stage/4-implementation
  • I'm not sure about how to proceed with the existing bug labels. For the previous workflow, it made sense for them to coexist. Going forward, I think they won't be necessary and could be archived and existing bugs could be mapped like "bug/new-report" → "stage/1-triaging" as well as "bug/confirmed" → "stage/4-implementation"
  • The templates will be reworked to set the labels accordingly and explain how users can start
    • Problem will be made a generic "Start here" template to avoid confusion
    • A "Design" template, which focuses on the problems and initiates a discussion
    • An "Implementation" template which assumes the design is clear and just focuses on describing how something should be implemented
Hi everyone! During FOSDEM, some things have moved quite quickly, and I only now find the time to hit you up here. We had a small meetup with @mfenniak, @famfo, @Gusted, @n0toose and @wetneb on Saturday and discussed things. There are no real minutes, but I'll share some things from the top of my head. The most important thing is that we discussed an idea on reorganizing the issue workflow so that it will work better. I [gave a talk about this very topic on Sunday](https://fosdem.org/2026/schedule/event/EXQFAR-forgejo-developer-centric-user-needs-and-design/), and also talked about the idea we had, so the changes I intend to make are kinda communicated to the public before being discussed here. I apologize for the rush, but assume that given the approval of several people during FOSDEM, this will be fine overall. I will try to go ahead with applying the changes. One request for everyone involved: I really appreciate feedback, and lack of feedback is what slowed down the iteration. So if you have something to share or to complain about, please bring it up here or in the [user research issue](https://codeberg.org/forgejo/user-research/issues/71). The things discussed during the meeting were basically: * For many issues, it is not clear for which group they are actionable (does it need user research input, or someone with technical skills to take a look?) * Why the workflow is confusing to users * likely due to the nature of having to choose between types * problem as a name for template and label still feels weird if you rather have a need (although it also says that you can describe a need) * Stages are likely clearer to understand and follow * fast-tracking is important, so marking trivial bugs as ready for implementation quickly is important * finding issues that are suggested to work on is difficult, because you might want to check all 3 gain labels (high, very high, nice to have) * filtering for "implentation" stage issues is easier, the gain labels can serve as an additional indication for priorities The changes I want to apply precisely are: * rename the "problem" label to "stage/1-triaging" * introduce scoped labels: * stage/2-research * stage/3-design * stage/4-implementation * I'm not sure about how to proceed with the existing bug labels. For the previous workflow, it made sense for them to coexist. Going forward, I think they won't be necessary and could be archived and existing bugs could be mapped like "bug/new-report" → "stage/1-triaging" as well as "bug/confirmed" → "stage/4-implementation" * The templates will be reworked to set the labels accordingly and explain how users can start * Problem will be made a generic "Start here" template to avoid confusion * A "Design" template, which focuses on the problems and initiates a discussion * An "Implementation" template which assumes the design is clear and just focuses on describing how something should be implemented

One aspect I find annoying is that the issue titles are prefixed with problem/bug/whatever. When a new issue is created, it's redundant. The issue title is prefixed with "problem", but there's also the label "problem". Afterwards, it gets confusing. The title might be prefixed with "bug", but the label might be "enhancement". Which one is it? Now, somebody could argue that it's the responsibility of the person that changed the label to also change the issue title. But why do it twice?

One aspect I find annoying is that the issue titles are prefixed with problem/bug/whatever. When a new issue is created, it's redundant. The issue title is prefixed with "problem", but there's also the label "problem". Afterwards, it gets confusing. The title might be prefixed with "bug", but the label might be "enhancement". Which one is it? Now, somebody could argue that it's the responsibility of the person that changed the label to also change the issue title. But why do it twice?
Author
Owner
Copy link

I am very open to removing the prefix in the title. It was present in the past templates as well and I didn't want to argue about such "unrelated" changes. Also, I didn't find a good abbreviation for "problem". If no one objects, I'll just drop it.

I am very open to removing the prefix in the title. It was present in the past templates as well and I didn't want to argue about such "unrelated" changes. Also, I didn't find a good abbreviation for "problem". If no one objects, I'll just drop it.

@fnetX wrote in #415 (comment):

The changes I want to apply precisely are:

* rename the "problem" label to "stage/1-triaging"
* introduce scoped labels:
 * stage/2-research
 * stage/3-design
 * stage/4-implementation

I have input here that is focused on one problem that I see reoccurring frequently; well meaning contributors want to add major features to Forgejo and jump directly into implementing those features. And this ends up reaching a frustrating state where they've committed a lot of work into something that nobody has ever committed "I would merge that!"

I have three thoughts to add in this area...

  • Processes should be (very slightly) different between two, or maybe even three, different types of issues:
    • The types:
      • Type 1 (bugs): Improvements to how Forgejo does what it already does. Bug fixes, reliability fixes, refactoring, test improvements, security patches, observability improvements, etc.
      • Type 2 (enh): Addition of capabilities to Forgejo that improves how Forgejo does what it already does. If you review the v14 blog post, I'd say almost everything highlighted in the blog post fits into this category, minus a couple that were so small they fit into the type 1 category.
      • Type 3 (feat): Features that expand the scope of Forgejo to new capabilities that don't exist today.
    • Type 1 changes typically don't need stage/2-research or stage/3-design labels.
    • Type 2 changes all stages apply.
    • Type 3 changes require a stage that isn't present here -- a decision point as to whether Forgejo is going to be expanded into new capabilities, or, whether the change proposal is rejected.
    • The type of issue can be identified in the triage stage.
  • I don't think there's a clear distinction to me between stages 2 and 3. I'd propose merging them as I see research as a part of design.
  • The important part of stages like this to me isn't that they exist, it's that it's clear how work transitions between the stages. I think this requires defining the roles & responsibilities that interact with this. Who can move an issue between these stages?
    • I don't have a complete answer here, but I propose that for Type 2 & Type 3 issues, it is necessary that a member of the Mergers team commit to supporting the issue sometime before it reaches stage/4-implementation. I'd call this a "Merger Sponsor".
@fnetX wrote in https://codeberg.org/forgejo/discussions/issues/415#issuecomment-10312916: > > The changes I want to apply precisely are: > > * rename the "problem" label to "stage/1-triaging" > > * introduce scoped labels: > > * stage/2-research > * stage/3-design > * stage/4-implementation I have input here that is focused on one problem that I see reoccurring frequently; well meaning contributors want to add major features to Forgejo and jump directly into implementing those features. And this ends up reaching a frustrating state where they've committed a lot of work into something that nobody has ever committed "I would merge that!" I have three thoughts to add in this area... - Processes should be (very slightly) different between two, or maybe even three, different types of issues: - The types: - **Type 1** (bugs): Improvements to how Forgejo does what it already does. Bug fixes, reliability fixes, refactoring, test improvements, security patches, observability improvements, etc. - **Type 2** (enh): Addition of capabilities to Forgejo that improves how Forgejo does what it already does. If you review the [v14 blog post](https://forgejo.org/2026-01-release-v14-0/), I'd say almost everything highlighted in the blog post fits into this category, minus a couple that were so small they fit into the type 1 category. - **Type 3** (feat): Features that expand the scope of Forgejo to new capabilities that don't exist today. - Type 1 changes typically don't need stage/2-research or stage/3-design labels. - Type 2 changes all stages apply. - Type 3 changes require a stage that isn't present here -- a decision point as to whether Forgejo is going to be expanded into new capabilities, or, whether the change proposal is rejected. - The type of issue can be identified in the triage stage. - I don't think there's a clear distinction to me between stages 2 and 3. I'd propose merging them as I see research as a part of design. - The important part of stages like this to me isn't that they exist, it's that it's clear how work transitions between the stages. I think this requires defining the roles & responsibilities that interact with this. Who can move an issue between these stages? - I don't have a complete answer here, but I propose that for Type 2 & Type 3 issues, it is necessary that a member of the Mergers team commit to supporting the issue sometime before it reaches stage/4-implementation. I'd call this a "Merger Sponsor".

@mfenniak wrote in #415 (comment):

I have input here that is focused on one problem that I see reoccurring frequently; well meaning contributors want to add major features to Forgejo and jump directly into implementing those features.

While we have forgejo-actions-feature-requests with instructions to wait until the feature is deemed ready, people regularly send code almost immediately. That suggests that at least some believe that writing code is the bottle neck.

@mfenniak wrote in https://codeberg.org/forgejo/discussions/issues/415#issuecomment-10504066: > I have input here that is focused on one problem that I see reoccurring frequently; well meaning contributors want to add major features to Forgejo and jump directly into implementing those features. While we have [forgejo-actions-feature-requests](https://code.forgejo.org/forgejo/forgejo-actions-feature-requests) _with instructions_ to wait until the feature is deemed ready, people regularly send code almost immediately. That suggests that at least some believe that writing code is the bottle neck.

@aahlenst wrote in #415 (comment):

While we have forgejo-actions-feature-requests with instructions to wait until the feature is deemed ready, people regularly send code almost immediately. That suggests that at least some believe that writing code is the bottle neck.

Yes, and that's unavoidable. I'd even say it's fine, as I've done this myself as well -- produce the idea and the implementation at the same time without knowing yet if it's wanted.

I think the clarity that is needed in the process will still have people doing this, but I want them to be informed as early as possible that they're taking a risk with their time. If someone proposes, let's say, "I want to add an VM manager to Forgejo" and starts working on it... I want them to know very early that this work requires a community decision as to whether Forgejo is going to be expanded into this new capability. If they sink 120hr of work into it, that doesn't make it more likely to land or not. Sunk cost shouldn't be a decision factor.

@aahlenst wrote in https://codeberg.org/forgejo/discussions/issues/415#issuecomment-10521964: > While we have [forgejo-actions-feature-requests](https://code.forgejo.org/forgejo/forgejo-actions-feature-requests) _with instructions_ to wait until the feature is deemed ready, people regularly send code almost immediately. That suggests that at least some believe that writing code is the bottle neck. Yes, and that's unavoidable. I'd even say it's fine, as I've done this myself as well -- produce the idea and the implementation at the same time without knowing yet if it's wanted. I think the clarity that is needed in the process will still have people doing this, but I want them to be informed as early as possible that they're taking a risk with their time. If someone proposes, let's say, "I want to add an VM manager to Forgejo" and starts working on it... I want them to know very early that this work requires a community decision as to whether Forgejo is going to be expanded into this new capability. If they sink 120hr of work into it, that doesn't make it more likely to land or not. Sunk cost shouldn't be a decision factor.
Author
Owner
Copy link

@mfenniak Thank you for your feedback. I am not sure if I understand it correctly. To me, your proposal sounds like we return to classifying things into bugs and feature requests, and something in between. However, I don't think that this works very well for the reasons explained in the talk and during the meeting.

How do you tell bugs and enhancements apart? Is forgejo/forgejo#10702 a bug fix or an enhancement? I labeled the issue enhancement, but IMHO it actually fixes the bug that the previous way to exclude label was just plain broken for most users (a bug). Why is it even necessary to spend time classifying the incoming issues into these categories?

I think that user research also helps for bug reports. There are a lot of them. How do you know which bugs are important to fix and which bugs are only a technical annoyance when someone really does something weird?

I don't agree to merging design and research. For me, these are two separate stages, and they are as similar as "design" and "implementation" could be merged into one. I want to focus on research and understanding users, but I'm not necessarily the best to draw conclusions from the input I have. Of course, software development is an iterative process. Sometimes, you need more input while designing something, but in general, I believe that this order of tasks ensures that we don't try to discuss solutions before we understand the problem.

Type 3 changes require a stage that isn't present here - a decision point as to whether Forgejo is going to be expanded into new capabilities, or, whether the change proposal is rejected.

IMHO this is addressed by the workflow I proposed. When research shows that something is not relevant, the unit won't enter design or implementation stage.

The type of issue can be identified in the triage stage.

What is the advantage of classifying issues in categories over my proposal of identifying in the triage stage if an issue should be moved forward to design or directly to design/implementation?

To me, the advantage of stages is that all issues can be treated similarly and pass through the units, and each unit has a defined set of responsible people:

  • Triage: Everyone.
  • Research: User research team and everyone interested in learning more about the problem
  • Design: Everyone interested in drawing conclusions based on research data
  • Implementation: Developers

The important part of stages like this to me isn't that they exist, it's that it's clear how work transitions between the stages. I think this requires defining the roles & responsibilities that interact with this. Who can move an issue between these stages?

This is an important aspect and I intend to work on clarifying this. I'll try to drop some early thoughts.

dealing with triage issues

  • strictly technical issues (say: tests, deadcode, code quality, refactoring, ...)
    • do you want to learn about and discuss the gain (for example: I want to refactor X ... what are the needs of a new system?): Move to research
    • do you want to discuss the technical aspects (for example: We have a clue what we want, but should we do it this way or that way?): Move to design
    • You think it should be implemented right away (I do trust the contributors to do the right thing here ... even if an issue is "moved too fast", it is essentially just using the old workflow): move to implementation
  • simple bugs that can likely be fixed easily
    • is it in an area that we want to rework anyway? move to research
    • else: move to implementation
  • potentially move involved bug fixes:
    • do you want to know if the bug is important to fix? Move to research
    • Do you think the bug needs to be fixed, but don't know how: move to design
  • is the user just having a problem (and we're basically providing technical support): I honestly don't yet know how to deal with them ... ideally, they are closed ASAP :)
  • you are not sure what to do: move to research

dealing with research issues

  • research is stuck and you feel it is unlikely to be important to anyone: close (basically the "gain/undefined" behaviour we have right now, we should create a fancy template for this)
  • research is stuck, but you think it is important: Ping the user research team or do research yourself
  • there is some research and you think it might be enough to start thinking about a solution: move to design
  • during the discussion, there is already a good idea about what to do: move to implementation
  • if you have data to add: just add a comment

dealing with design issues

  • issues are stuck and need more input: maybe move back to research?
  • the issue is stuck, although there is probably enough input: ... not sure how we can force us great ideas :D
  • the issue is somewhat clear and can be implemented this way: move to implementation
@mfenniak Thank you for your feedback. I am not sure if I understand it correctly. To me, your proposal sounds like we return to classifying things into bugs and feature requests, and something in between. However, I don't think that this works very well for the reasons explained in the talk and during the meeting. How do you tell bugs and enhancements apart? Is https://codeberg.org/forgejo/forgejo/pulls/10702 a bug fix or an enhancement? I labeled the issue enhancement, but IMHO it actually fixes the bug that the previous way to exclude label was just plain broken for most users (a bug). Why is it even necessary to spend time classifying the incoming issues into these categories? I think that user research also helps for bug reports. There are a lot of them. How do you know which bugs are important to fix and which bugs are only a technical annoyance when someone really does something weird? I don't agree to merging design and research. For me, these are two separate stages, and they are as similar as "design" and "implementation" could be merged into one. I want to focus on research and understanding users, but I'm not necessarily the best to draw conclusions from the input I have. Of course, software development is an iterative process. Sometimes, you need more input while designing something, but in general, I believe that this order of tasks ensures that we don't try to discuss solutions before we understand the problem. > Type 3 changes require a stage that isn't present here - a decision point as to whether Forgejo is going to be expanded into new capabilities, or, whether the change proposal is rejected. IMHO this is addressed by the workflow I proposed. When research shows that something is not relevant, the unit won't enter design or implementation stage. > The type of issue can be identified in the triage stage. What is the advantage of classifying issues in categories over my proposal of identifying in the triage stage if an issue should be moved forward to design or directly to design/implementation? To me, the advantage of stages is that all issues can be treated similarly and pass through the units, and each unit has a defined set of responsible people: * Triage: Everyone. * Research: User research team and everyone interested in learning more about the problem * Design: Everyone interested in drawing conclusions based on research data * Implementation: Developers > The important part of stages like this to me isn't that they exist, it's that it's clear how work transitions between the stages. I think this requires defining the roles & responsibilities that interact with this. Who can move an issue between these stages? This is an important aspect and I intend to work on clarifying this. I'll try to drop some early thoughts. ### dealing with triage issues * strictly technical issues (say: tests, deadcode, code quality, refactoring, ...) * do you want to learn about and discuss the gain (for example: I want to refactor X ... what are the needs of a new system?): Move to research * do you want to discuss the technical aspects (for example: We have a clue what we want, but should we do it this way or that way?): Move to design * You think it should be implemented right away (I do trust the contributors to do the right thing here ... even if an issue is "moved too fast", it is essentially just using the old workflow): move to implementation * simple bugs that can likely be fixed easily * is it in an area that we want to rework anyway? move to research * else: move to implementation * potentially move involved bug fixes: * do you want to know if the bug is important to fix? Move to research * Do you think the bug needs to be fixed, but don't know how: move to design * is the user just having a problem (and we're basically providing technical support): I honestly don't yet know how to deal with them ... ideally, they are closed ASAP :) * you are not sure what to do: move to research ### dealing with research issues * research is stuck and you feel it is unlikely to be important to anyone: close (basically the "gain/undefined" behaviour we have right now, we should create a fancy template for this) * research is stuck, but you think it is important: Ping the user research team or do research yourself * there is some research and you think it might be enough to start thinking about a solution: move to design * during the discussion, there is already a good idea about what to do: move to implementation * if you have data to add: just add a comment ### dealing with design issues * issues are stuck and need more input: maybe move back to research? * the issue is stuck, although there is probably enough input: ... not sure how we can force us great ideas :D * the issue is somewhat clear and can be implemented this way: move to implementation
Author
Owner
Copy link

Instead of classifying into bugs, enhancement and features, I would rather think that the following classifications would make sense:

  • Which input is needed? Is it technical or design? For example, an issue in research might be actionable for me (learning about users), or it requires input from Forgejo contributors (what are the needs of a refactored x component). Similarly, an issue in design stage might require UX input on how to make it work / look, or input on how to solve things in code. Sometimes both.
  • How complex is it? This might address your idea of sorting things into large and small enhancement. Some bugs are clear and straightforward to fix. Some are more complex. Same for all other changes. Things that are not complex require less design input, I suppose.

Also, I'd like to pick up the idea that someone shared with me at FOSDEM and that I discussed with some contributors. Something like an "office hour" or a regular meeting might allow external contributors to put things onto the agenda. If someone wants to work on something that is buried among hundreds of issues, a live meeting would be the chance to discuss how to move forward and maybe move the issue to a next stage. I would be open to doing such a meeting at least once a month.

Instead of classifying into bugs, enhancement and features, I would rather think that the following classifications would make sense: * Which input is needed? Is it technical or design? For example, an issue in research might be actionable for me (learning about users), or it requires input from Forgejo contributors (what are the needs of a refactored x component). Similarly, an issue in design stage might require UX input on how to make it work / look, or input on how to solve things in code. Sometimes both. * How complex is it? This might address your idea of sorting things into large and small enhancement. Some bugs are clear and straightforward to fix. Some are more complex. Same for all other changes. Things that are not complex require less design input, I suppose. Also, I'd like to pick up the idea that someone shared with me at FOSDEM and that I discussed with some contributors. Something like an "office hour" or a regular meeting might allow external contributors to put things onto the agenda. If someone wants to work on something that is buried among hundreds of issues, a live meeting would be the chance to discuss how to move forward and maybe move the issue to a next stage. I would be open to doing such a meeting at least once a month.

I really like the Which input is needed? part, because it is quite actionable.

  • New bug? => needs some investigation (minimal reproducer)
  • Confirmed "hard" bug => needs a contributor (with a test and a fix)
  • New request? => needs some community discussion (user gain, UX strategy, implementation complexity, estimated maintainer burden)

Just like PRs might need:

  • Some help to get started
  • help to add tests
  • a first review
  • help to fix the CI
  • a final review+merge

I think the current status/labels do a poor work at conveying this Which input is needed? information (and its evolution).

I really like the `Which input is needed?` part, because it is quite actionable. - New bug? => needs some investigation (minimal reproducer) - Confirmed "hard" bug => needs a contributor (with a test and a fix) - New request? => needs some community discussion (user gain, UX strategy, implementation complexity, estimated maintainer burden) Just like PRs might need: - Some help to get started - help to add tests - a first review - help to fix the CI - a final review+merge I think the current status/labels do a poor work at conveying this `Which input is needed?` information (and its evolution).

A lot of what you're saying @fnetX makes sense to me, and I'll reflect and think on it. I want to raise two particular points in the short-term:

@fnetX wrote in #415 (comment):

To me, the advantage of stages is that all issues can be treated similarly and pass through the units, and each unit has a defined set of responsible people:

* Triage: Everyone.
* Research: User research team and everyone interested in learning more about the problem
* Design: Everyone interested in drawing conclusions based on research data
* Implementation: Developers

This sounds to me like you're expecting every issue to be touched by different hands for each of these areas of responsibility. Is that what you intend by this?

I think you'll agree with this perspective: I want simple things to remain simple. I want to spend time coding, not spend time moving bugs through a four-stage process. 😉

I asked "Who can move an issue between these stages?" because I was hoping for an easy answer like "we'll trust every contributor", and I'm concerned that the answer I'm hearing might be "the user research team is a gate for the 'research' stage".

@fnetX wrote in #415 (comment):

  • How complex is it? This might address your idea of sorting things into large and small enhancement. Some bugs are clear and straightforward to fix. Some are more complex. Same for all other changes. Things that are not complex require less design input, I suppose.

Complexity of the feature is not what I'm concerned about with respect to large enhancements. There are feature proposals in the Forgejo repo that I don't believe belong in this project at all. It doesn't matter whether they're complicated or not.

The specific wording was "Features that expand the scope of Forgejo to new capabilities that don't exist today", and "a decision point as to whether Forgejo is going to be expanded into new capabilities, or, whether the change proposal is rejected."

I'll play hypothetical... actually, let's make it something I wish existed in Forgejo. I think it would be very cool if I could program a little script into Forgejo that filtered my notifications. I have complex rules I wish I could apply. "In the Forgejo repo, if it's a cascading PR -> /dev/null, if its a PR touching CSS -> /dev/null, if it's a comment that includes 'PostgreSQL' then ping me, etc., etc." I want a complex notification engine with access to the internal state of a notification that can run arbitrary rules against it and decide whether to send me an email or not.

But, I don't think this should exist in Forgejo. I think it belongs in my email client. Its like taking a whole other program and shoving it into Forgejo, and it's the kind of program that would require it's own software team to maintain. It'd be cool if it was there, but it would spread the contributor resources of Forgejo too wide across too many features, and wouldn't focus on the core capability of collaborative software development. If I created the feature, forced someone to merge it, and then disappeared forever, I've effectively offloaded maintenance of my work to the Forgejo team.

So, if I proposed this feature, the best outcome would be if the contributors could give me "no, we won't include that in Forgejo" as an answer, quickly and decisively.

A lot of what you're saying @fnetX makes sense to me, and I'll reflect and think on it. I want to raise two particular points in the short-term: @fnetX wrote in https://codeberg.org/forgejo/discussions/issues/415#issuecomment-10560456: > To me, the advantage of stages is that all issues can be treated similarly and pass through the units, and each unit has a defined set of responsible people: > > * Triage: Everyone. > * Research: User research team and everyone interested in learning more about the problem > * Design: Everyone interested in drawing conclusions based on research data > * Implementation: Developers This sounds to me like you're expecting every issue to be touched by different hands for each of these areas of responsibility. Is that what you intend by this? I think you'll agree with this perspective: I want simple things to remain simple. I want to spend time coding, not spend time moving bugs through a four-stage process. 😉 I asked "Who can move an issue between these stages?" because I was hoping for an easy answer like "we'll trust every contributor", and I'm concerned that the answer I'm hearing might be "the user research team is a gate for the 'research' stage". @fnetX wrote in https://codeberg.org/forgejo/discussions/issues/415#issuecomment-10560570: > * How complex is it? This might address your idea of sorting things into large and small enhancement. Some bugs are clear and straightforward to fix. Some are more complex. Same for all other changes. Things that are not complex require less design input, I suppose. Complexity of the feature is not what I'm concerned about with respect to large enhancements. There are feature proposals in the Forgejo repo that I don't believe belong in this project at all. It doesn't matter whether they're complicated or not. The specific wording was "Features that expand the scope of Forgejo to new capabilities that don't exist today", and "a decision point as to whether Forgejo is going to be expanded into new capabilities, or, whether the change proposal is rejected." I'll play hypothetical... actually, let's make it something I wish existed in Forgejo. I think it would be very cool if I could program a little script into Forgejo that filtered my notifications. I have complex rules I wish I could apply. "In the Forgejo repo, if it's a cascading PR -> /dev/null, if its a PR touching CSS -> /dev/null, if it's a comment that includes 'PostgreSQL' then ping me, etc., etc." I want a complex notification engine with access to the internal state of a notification that can run arbitrary rules against it and decide whether to send me an email or not. But, I don't think this should exist in Forgejo. I think it belongs in my email client. Its like taking a whole other program and shoving it into Forgejo, and it's the kind of program that would require it's own software team to maintain. It'd be cool if it was there, but it would spread the contributor resources of Forgejo too wide across too many features, and wouldn't focus on the core capability of collaborative software development. If I created the feature, forced someone to merge it, and then disappeared forever, I've effectively offloaded maintenance of my work to the Forgejo team. So, if I proposed this feature, the best outcome would be if the contributors could give me "no, we won't include that in Forgejo" as an answer, quickly and decisively.

The underlying problem may still persist, even though the particular suggested enhancement isn't worth doing as realized during triage. I do get that a quick yay-or-nay decision is desirable, but that leaves away nuance worth saving here.

Example for your particular example: The underlying problem in the issue, as far as I see, is "A user is overwhelmed by their notification inbox". Closing the enhancement proposal conveyed in the same step during triage would ignore the opportunity for further improvement, just not in the exact way suggested, e.g. exposing more metadata to email/RSS clients.

Am I doing this "interacting on forgejo/discussions" thing right? Please let me know if not.

The underlying *problem* may still persist, even though the particular suggested enhancement isn't worth doing as realized during triage. I do get that a quick yay-or-nay decision is desirable, but that leaves away nuance worth saving here. Example for your particular example: The underlying problem in the issue, as far as I see, is "A user is overwhelmed by their notification inbox". Closing the enhancement proposal conveyed in the same step during triage would ignore the opportunity for further improvement, just not in the exact way suggested, e.g. exposing more metadata to email/RSS clients. <sub>Am I doing this "interacting on forgejo/discussions" thing right? Please let me know if not.</sub>
Author
Owner
Copy link

This sounds to me like you're expecting every issue to be touched by different hands for each of these areas of responsibility. Is that what you intend by this?

Not necessarily, no.

I asked "Who can move an issue between these stages?" because I was hoping for an easy answer like "we'll trust every contributor", and I'm concerned that the answer I'm hearing might be "the user research team is a gate for the 'research' stage".

Sorry. The easy answer is "every contributor", indeed. I was focusing on guidelines about when things are moved, but everyone can come to the conclusion. The explicit goal of the workflow is to avoid a bottleneck in user research or design. I find it quite unlikely that I can move all these issues on my own.

At the same time, I'd like to encourage everyone to participate in the process. It would be great if people not only move issues from triage to design, but also help to understand users and discuss solutions. The diversity of knowledge is probably a win for great ideas.

Basically, the process formalizes what happens in an ideal issue discussion. So far, some issues also have discussions among contributors who try to understand the problem and discuss various ideas. But the process should make it clear where an issue is in, and also encourage to go through these stages as often as possible. I believe that considering approaches for 2 days is a win for most of our reported issues, because it avoids narrowing down a specific path too early. However, I can second the sentiment to sometimes fast-track things, and I'm sure there are many cases where this is fine. Finding the sweet spot is a thing we need to learn, it will probably evolve over time.

So, if I proposed this feature, the best outcome would be if the contributors could give me "no, we won't include that in Forgejo" as an answer, quickly and decisively.

Thank you for this example. IMHO, with the new workflow, it should basically be impossible (or at least very discouraged and hard) to propose such a feature. However, you can create problem reports. For example, they would rather look like:

  • I have too many notifications. Most of them are not relevant.
  • I cannot find the relevant ones.
  • I use search through them.
  • I open one, but it only has frontend code in them etc.

Based on the needs, we'd then discuss potential solutions. At this stage, someone could actually come up with a complex filtering system. But someone else (or the same person) could also propose using external software: Whether an email client, project management, a third-party CLI tool. Evaluating whether the option actually solves the user's need is then the process.

I believe that the outcome could sometimes be surprising. Maybe the user tried to use email filters, but something does not work very well. Maybe adding another header for filtering, or a new API for another tool is the outcome of the problem description. Something that is much simpler and would never have been considered if we started discussing the solution instead of the problem.

> This sounds to me like you're expecting every issue to be touched by different hands for each of these areas of responsibility. Is that what you intend by this? Not necessarily, no. > I asked "Who can move an issue between these stages?" because I was hoping for an easy answer like "we'll trust every contributor", and I'm concerned that the answer I'm hearing might be "the user research team is a gate for the 'research' stage". Sorry. The easy answer is "every contributor", indeed. I was focusing on guidelines about when things are moved, but everyone can come to the conclusion. The explicit goal of the workflow is to avoid a bottleneck in user research or design. I find it quite unlikely that I can move all these issues on my own. At the same time, I'd like to encourage everyone to participate in the process. It would be great if people not only move issues from triage to design, but also help to understand users and discuss solutions. The diversity of knowledge is probably a win for great ideas. Basically, the process formalizes what happens in an ideal issue discussion. So far, some issues also have discussions among contributors who try to understand the problem and discuss various ideas. But the process should make it clear where an issue is in, and also encourage to go through these stages as often as possible. I believe that considering approaches for 2 days is a win for most of our reported issues, because it avoids narrowing down a specific path too early. However, I can second the sentiment to sometimes fast-track things, and I'm sure there are many cases where this is fine. Finding the sweet spot is a thing we need to learn, it will probably evolve over time. > So, if I proposed this feature, the best outcome would be if the contributors could give me "no, we won't include that in Forgejo" as an answer, quickly and decisively. Thank you for this example. IMHO, with the new workflow, it should basically be impossible (or at least very discouraged and hard) to propose such a feature. However, you can create problem reports. For example, they would rather look like: * I have too many notifications. Most of them are not relevant. * I cannot find the relevant ones. * I use search through them. * I open one, but it only has frontend code in them etc. Based on the needs, we'd then discuss potential solutions. At this stage, someone could actually come up with a complex filtering system. But someone else (or the same person) could also propose using external software: Whether an email client, project management, a third-party CLI tool. Evaluating whether the option actually solves the user's need is then the process. I believe that the outcome could sometimes be surprising. Maybe the user tried to use email filters, but something does not work very well. Maybe adding another header for filtering, or a new API for another tool is the outcome of the problem description. Something that is much simpler and would never have been considered if we started discussing the solution instead of the problem.

@mfenniak wrote in #415 (comment):

I think the clarity that is needed in the process will still have people doing this, but I want them to be informed as early as possible that they're taking a risk with their time.

I agree with the objective. But I don't think that any process can fix it. (This is no criticism of the process proposed here.)

I think the problem is not the process, its stages or labels, but that people aren't set up to succeed.

CONTRIBUTING.md doesn't send me immediately to the Contribution Guide. It's literally the last link in the document.

The Contribution Guide is way to extensive for newcomers. None of the titles suggest that I can learn how to open an issue or what it is expected from me when I want to work on something.

CONTRIBUTING.md should be converted into a quick start guide for newcomers with very simple, actionable instructions.

You encountered a bug? File a problem.
You want a new feature? File a problem.
You want a new feature and are ready to implement it? Do X.
You want want to fix a bug? Do Y.
You didn't get a response? Do Z.

If somebody needs details, refer them to the appropriate section in the Contribution Guide.

CONTRIBUTING.md should also encourage discussion and iteration. There's a tendency in our industry that code is the most important thing. Nobody enjoys reviews due to the delay and rework. That results in large PR drops out of nowhere and the expectation that they should be perfect. But I want people to discuss their ideas first and send imperfect PRs. That allows iterating on ideas and come up with better solutions.

@mfenniak wrote in https://codeberg.org/forgejo/discussions/issues/415#issuecomment-10540120: > I think the clarity that is needed in the process will still have people doing this, but I want them to be informed as early as possible that they're taking a risk with their time. I agree with the objective. But I don't think that any process can fix it. (This is no criticism of the process proposed here.) I think the problem is not the process, its stages or labels, but that people aren't set up to succeed. [CONTRIBUTING.md](https://codeberg.org/forgejo/forgejo/src/commit/e811313298376005f4a96f8d0a17d5ca54b89804/CONTRIBUTING.md) doesn't send me immediately to the [Contribution Guide](https://forgejo.org/docs/next/contributor/). It's literally the last link in the document. The [Contribution Guide](https://forgejo.org/docs/next/contributor/) is way to extensive for newcomers. None of the titles suggest that I can learn how to open an issue or what it is expected from me when I want to work on something. CONTRIBUTING.md should be converted into a quick start guide for newcomers with very simple, actionable instructions. You encountered a bug? File a problem. You want a new feature? File a problem. You want a new feature and are ready to implement it? Do X. You want want to fix a bug? Do Y. You didn't get a response? Do Z. If somebody needs details, refer them to the appropriate section in the Contribution Guide. CONTRIBUTING.md should also encourage discussion and iteration. There's a tendency in our industry that code is the most important thing. Nobody enjoys reviews due to the delay and rework. That results in large PR drops out of nowhere and the expectation that they should be perfect. But I want people to discuss their ideas first and send imperfect PRs. That allows iterating on ideas and come up with better solutions.
Author
Owner
Copy link

I agree to the need for more and better guides for new contributors. But I see this as a separate discussion and would like to focus on the workflow and clarifying it.

I could, however, document the workflow I have in mind for contributors and send both at the same time. It won't help with the discovery part, but maybe improve clarity?

I agree to the need for more and better guides for new contributors. But I see this as a separate discussion and would like to focus on the workflow and clarifying it. I could, however, document the workflow I have in mind for contributors and send both at the same time. It won't help with the discovery part, but maybe improve clarity?

@fnetX wrote in #415 (comment):

But I see this as a separate discussion and would like to focus on the workflow and clarifying it.

I agree. My objective was not to start discussing the contribution guide, but to point out that there are problems that are unlikely to be rectified by the process alone, no matter how good it is.

I'd appreciate if somebody else would start a separate discussion regarding CONTRIBUTING.md.

@fnetX wrote in https://codeberg.org/forgejo/discussions/issues/415#issuecomment-10626683: > But I see this as a separate discussion and would like to focus on the workflow and clarifying it. I agree. My objective was not to start discussing the contribution guide, but to point out that there are problems that are unlikely to be rectified by the process alone, no matter how good it is. I'd appreciate if somebody else would start a separate discussion regarding `CONTRIBUTING.md`.

@aahlenst wrote in #415 (comment):

@fnetX wrote in #415 (comment):

But I see this as a separate discussion and would like to focus on the workflow and clarifying it.

I agree. My objective was not to start discussing the contribution guide, but to point out that there are problems that are unlikely to be rectified by the process alone, no matter how good it is.

I'd appreciate if somebody else would start a separate discussion regarding CONTRIBUTING.md.

Have done so here.

@aahlenst wrote in https://codeberg.org/forgejo/discussions/issues/415#issuecomment-10665851: > @fnetX wrote in #415 (comment): > > > But I see this as a separate discussion and would like to focus on the workflow and clarifying it. > > I agree. My objective was not to start discussing the contribution guide, but to point out that there are problems that are unlikely to be rectified by the process alone, no matter how good it is. > > I'd appreciate if somebody else would start a separate discussion regarding `CONTRIBUTING.md`. Have done so [here](https://codeberg.org/forgejo/discussions/issues/449).

@fnetX Following up on the discussion that took place during the release party, I'd like to clarify Forgejo's process for features that increase the scope of Forgejo's capabilities. In our previous discussion on this topic, you indicated...

Thank you for this example. IMHO, with the new workflow, it should basically be impossible (or at least very discouraged and hard) to propose such a feature. However, you can create problem reports.

But I have three concerns with this:

  1. We already have features like this, which are sitting in limbo
  2. Contributors can always create pull requests without going through the documented process here
  3. It's very idealistic and I don't know what tools we'll use to encourage or enforce a process

I'd like to draft a policy along the lines of the release party discussion, where these scope increases would require contributor or merger sponsorship, and would be rejected with the "no" options we discussed if that sponsorship isn't present. My concern is that I don't want to pursue such a proposal without consideration for how it interacts with or conflicts with your workflow proposals. Do you think that such a proposal would conflict with your workflow proposals here, or, is it possible that it's a complimentary idea? Should such a policy be integrated with this workflow, or independent, (or I suppose non-existent if your opinion leans that way)?

@fnetX Following up on the discussion that took place during the [release party](https://codeberg.org/forgejo/discussions/issues/459), I'd like to clarify Forgejo's process for features that increase the scope of Forgejo's capabilities. In our previous discussion on this topic, you indicated... > Thank you for this example. IMHO, with the new workflow, it should basically be impossible (or at least very discouraged and hard) to propose such a feature. However, you can create problem reports. But I have three concerns with this: 1. We already have features like this, which are sitting in limbo 2. Contributors can always create pull requests without going through the documented process here 3. It's very idealistic and I don't know what tools we'll use to encourage or enforce a process I'd like to draft a policy along the lines of the release party discussion, where these scope increases would require contributor or merger sponsorship, and would be rejected with the "no" options we discussed if that sponsorship isn't present. My concern is that I don't want to pursue such a proposal without consideration for how it interacts with or conflicts with your workflow proposals. Do you think that such a proposal would conflict with your workflow proposals here, or, is it possible that it's a complimentary idea? Should such a policy be integrated with this workflow, or independent, (or I suppose non-existent if your opinion leans that way)?
Author
Owner
Copy link

@mfenniak There might be a conflict, indeed. Depends on the scope of your proposal.

I am working on a proposal on what the workflow should look like exactly. It is what is missing to make forgejo/forgejo#12001 ready. It focuses on explaining the stages issues can be in, who is responsible for each stage, under which issues should be moved across stages, fast-tracked etc.

It would not conflict if it focuses on the aspect of "out of scope" issues. Technically, an issue could be "accepted" as per my workflow (e.g. a lot of users need it), but still out of scope for Forgejo. In this case, I hope we would meet again and decide in my "design" stage, that the user need should be addressed by providing a nice integration with another software, for instance.

The thing that currently blocks me is that I do not just want to dump yet another wall of text into the contributor docs. I want it to be short enough, so that everyone can read it, but at the same time I see that the docs need some love and restructuring anyway. And I kinda got stuck in deciding how much I want to improve the contributing docs.

@mfenniak There might be a conflict, indeed. Depends on the scope of your proposal. I am working on a proposal on what the workflow should look like exactly. It is what is missing to make https://codeberg.org/forgejo/forgejo/pulls/12001 ready. It focuses on explaining the stages issues can be in, who is responsible for each stage, under which issues should be moved across stages, fast-tracked etc. It would not conflict if it focuses on the aspect of "out of scope" issues. Technically, an issue could be "accepted" as per my workflow (e.g. a lot of users need it), but still out of scope for Forgejo. In this case, I hope we would meet again and decide in my "design" stage, that the user need should be addressed by providing a nice integration with another software, for instance. The thing that currently blocks me is that I do not just want to dump yet another wall of text into the contributor docs. I want it to be short enough, so that everyone can read it, but at the same time I see that the docs need some love and restructuring anyway. And I kinda got stuck in deciding how much I want to improve the contributing docs.

OK, I will hold on complicating the situation any further than I already have; let's get your proposal resolved first. Let me know if you want or need any help in that work.

OK, I will hold on complicating the situation any further than I already have; let's get your proposal resolved first. Let me know if you want or need any help in that work.

I've been working on F3 for over a year and started to contribute to the maintenance of the F3 driver for Forgejo in 2026. It is a very large contribution (see the latest update) that faces the same challenges as other large new features described here.

The path to getting it merged and maintained long term is rather clear, at least to me. My feeling is that if this process needs to be explained to someone contributing a similarly large feature, it will require learning how to contribute large changes to a Free Software project. I don't think it is a documentation issue, it is a matter of climbing the learning curve. Here are two examples of the work I'm currently doing that hopefully illustrate what I mean:

  • Before the F3 driver for Forgejo update is merged in, I need to demonstrate that I can be a trusted member of the Forgejo community in the long run. Otherwise the maintenance of this driver will land on someone else, which is a blocker. Earning that trust cannot be described in a documentation, it is a complex mixture that takes months, sometime years.

  • I rely on other Forgejo contributors to spend a significant amount of time reviewing the F3 driver. If I just wait for that to happen, it will stay in limbo forever. I need to create the conditions for these reviewers to be a lot more likely to take an interest in my feature. For instance I began to take my share of daily chores (reviews, CI moderation, scrubbing old pull requests) and it is now part of my daily routine. Another example is the iterations I've gone through in the past months to simplify the permission system F3 needs and make it immediately beneficial for Forgejo.

In conclusion, I think that if the author of a feature is stuck in limbo and feeling powerless to take even the simplest step to unblock the situation, they should revert to contributing something simpler and grow from there. That is common sense but it could be documented and, IMHO, resolve most of the problems discussed here.

I've been [working on F3 for over a year](https://code.forgejo.org/limiting-factor?tab=activity) and started to contribute to the maintenance of the F3 driver for Forgejo in 2026. It is a very large contribution (see [the latest update](https://codeberg.org/forgejo/forgejo/pulls/12500/files)) that faces the same challenges as other large new features described here. The path to getting it merged and maintained long term is rather clear, at least to me. My feeling is that if this process needs to be explained to someone contributing a similarly large feature, it will require learning how to contribute large changes to a Free Software project. I don't think it is a documentation issue, it is a matter of climbing the learning curve. Here are two examples of the work I'm currently doing that hopefully illustrate what I mean: - Before the F3 driver for Forgejo update is merged in, I need to demonstrate that I can be a trusted member of the Forgejo community in the long run. Otherwise the maintenance of this driver will land on someone else, which is a blocker. Earning that trust cannot be described in a documentation, it is a complex mixture that takes months, sometime years. - I rely on other Forgejo contributors to spend a significant amount of time reviewing the F3 driver. If I just wait for that to happen, it will stay in limbo forever. I need to create the conditions for these reviewers to be a lot more likely to take an interest in my feature. For instance I began to take my share of daily chores (reviews, CI moderation, scrubbing old pull requests) and it is now part of my daily routine. Another example is the iterations I've gone through in the past months to simplify the permission system F3 needs and make it [immediately beneficial for Forgejo](https://codeberg.org/forgejo/design/issues/63). In conclusion, I think that if the author of a feature is stuck in limbo and feeling powerless to take even the simplest step to unblock the situation, they should revert to contributing something simpler and grow from there. That is common sense but it could be documented and, IMHO, resolve most of the problems discussed here.
Author
Owner
Copy link

I have finally found the time to document the workflow I have in mind. Looking forward to your feedback in forgejo/docs#1983

I am sorry that I had this stall for too long. While I was talking a lot about this with others (for example during FOSS Backstage Design) and reading about the workflows of other projects, I think I let this topic sit for too long and it would have been better to have iterated on it more actively. Sorry again.

One of the blockers is that I have a vision of how the workflow can look like, but I find it really hard to communicate my view in a way that is brief enough so that all contributors can seriously be expected to read or at least scan it. I hope that the current version is good enough for a start.

If you're open to giving it a try, I'd be very happy to finally start with working more actively in the issue tracker again. While triaging issues, one thing I run into very quickly is the fact that my mental model already wants to classify issues into the stages, which is not yet possible. Looking forward to doing that.

I have finally found the time to document the workflow I have in mind. Looking forward to your feedback in https://codeberg.org/forgejo/docs/pulls/1983 I am sorry that I had this stall for too long. While I was talking a lot about this with others (for example during FOSS Backstage Design) and reading about the workflows of other projects, I think I let this topic sit for too long and it would have been better to have iterated on it more actively. Sorry again. One of the blockers is that I have a vision of how the workflow can look like, but I find it really hard to communicate my view in a way that is brief enough so that all contributors can seriously be expected to read or at least scan it. I hope that the current version is good enough for a start. If you're open to giving it a try, I'd be very happy to finally start with working more actively in the issue tracker again. While triaging issues, one thing I run into very quickly is the fact that my mental model already wants to classify issues into the stages, which is not yet possible. Looking forward to doing that.
Author
Owner
Copy link

I'm moving some discussion from forgejo/docs#1983 (comment) and comments above, because they are not really related to the documentation and maybe not even to my workflow in particular.

I do not have a strong opinion about how to classify the importance of issues. I see these methods:

  • Conclusion only, basically the gain labels we have right now. I'm fine with keeping it. Downside is that it is not always obvious why the issue has been classified as this, and you have to fully trust the triagers to classify it correctly. Since this was mostly me in the past, I didn't really feel comfortable with forcing my opinion on all the contributors. Also, with the new method, I felt like gain was becoming inappropriate. A problem has no gain, and thinking of "the gain of solving this problem" felt a little complex and I wanted to express things in a simpler way.
  • Affects+Impact: Try to use at least some more transparent classification. This is what I suggested so far, mostly because I think it is easy to judge these parameters. Affects is a quantitative classification based on how much users report being affected or are likely affected by the nature of the problem. Impact is a qualitative measurement for the severity (from minor annoyance to data loss, basically).
  • Affects+Impact+Complexity: When there are two things labeled "affects many" and same impact level (let's think of: need for moderation tooling and a little annoying bug, both could affect the same users and not fixing it has probably similar impact), the complexity level could tell them apart.
  • some other mixture

CC @mahlzahn

I'm moving some discussion from https://codeberg.org/forgejo/docs/pulls/1983#issuecomment-16022861 and comments above, because they are not really related to the documentation and maybe not even to my workflow in particular. I do not have a strong opinion about how to classify the importance of issues. I see these methods: * Conclusion only, basically the gain labels we have right now. I'm fine with keeping it. Downside is that it is not always obvious *why* the issue has been classified as this, and you have to fully trust the triagers to classify it correctly. Since this was mostly me in the past, I didn't really feel comfortable with forcing my opinion on all the contributors. Also, with the new method, I felt like gain was becoming inappropriate. A problem has no gain, and thinking of "the gain of solving this problem" felt a little complex and I wanted to express things in a simpler way. * Affects+Impact: Try to use at least some more transparent classification. This is what I suggested so far, mostly because I think it is easy to judge these parameters. Affects is a quantitative classification based on how much users report being affected or are likely affected by the nature of the problem. Impact is a qualitative measurement for the severity (from minor annoyance to data loss, basically). * Affects+Impact+Complexity: When there are two things labeled "affects many" and same impact level (let's think of: need for moderation tooling and a little annoying bug, both could affect the same users and not fixing it has probably similar impact), the complexity level could tell them apart. * some other mixture CC @mahlzahn
Author
Owner
Copy link

Thank you for your feedback. I think both PRs are ready for a final review now.

I removed the mention of the impact and affects label. They are not essential for the next step. I'd be happy to discuss the classification in the future.

Thank you for your feedback. I think both PRs are ready for a final review now. I removed the mention of the impact and affects label. They are not essential for the next step. I'd be happy to discuss the classification in the future.
Author
Owner
Copy link

I also created the stage labels (2-4) and started classifying some issues to get some early experiences for the workflow. Since the problem label can only be renamed after the templates are merged, the exclusive scope does not yet apply.

I also created the stage labels (2-4) and started classifying some issues to get some early experiences for the workflow. Since the problem label can only be renamed after the templates are merged, the exclusive scope does not yet apply.

Reviewing the issue_workflow.md document, I feel skeptical, and worry that this process will become a barrier to the development of work. But, I'm trying to be cautious in my feedback: (a) being involved in creating software development processes isn't what I want to be doing, so I don't want to put myself in a literal critical path (where I'm a critic, critic-al 😉). (b) the success of a process really has a lot to do with the people who are involved, and their ability to recognize the right exceptions / fast-paths, and to favour good outcomes over process details.

If anyone isn't operating the process the way that the community expects, the outcomes that we should have together are: understanding that we're all trying to make Forgejo better, communication and transparency about what happened, what was expected, and what went wrong, and a fundamental desire to collect feedback and iterate towards both personal improvement and process improvement.

I think there's a tendency within our community to default to "I don't like what's going on over there (some issue, some chat), and so I'm going to ignore it". I'm worried that I will personally be taking issues through this process in a way that someone else doesn't like -- probably too fast, probably with just the input of one or two trusted collaborators -- and if that's the case then I don't want to find people fuming in the background quietly. It would be much healthier for everyone if that is happening for transparent communication to occur.

Reviewing the [issue_workflow.md](https://codeberg.org/forgejo/docs/src/commit/3d15eedc195e8593edfa7e19dae4fef76fb65e4e/docs/contributor/issue_workflow.md) document, I feel skeptical, and worry that this process will become a barrier to the development of work. But, I'm trying to be cautious in my feedback: (a) being involved in creating software development processes isn't what I want to be doing, so I don't want to put myself in a literal critical path (where I'm a critic, critic-al 😉). (b) the success of a process really has a lot to do with the people who are involved, and their ability to recognize the right exceptions / fast-paths, and to favour good outcomes over process details. If anyone isn't operating the process the way that the community expects, the outcomes that we should have together are: understanding that we're all trying to make Forgejo better, communication and transparency about what happened, what was expected, and what went wrong, and a fundamental desire to collect feedback and iterate towards both personal improvement and process improvement. I think there's a tendency within our community to default to "I don't like what's going on over there (*some issue*, *some chat*), and so I'm going to ignore it". I'm worried that I will personally be taking issues through this process in a way that someone else doesn't like -- probably too fast, probably with just the input of one or two trusted collaborators -- and if that's the case then I don't want to find people fuming in the background quietly. It would be much healthier for everyone if that is happening for transparent communication to occur.
Author
Owner
Copy link

@mfenniak thank you for the feedback. I think the change of the process is a risk, but has significant improvement to do better.

I think the traditional workflow in free/libre software development (issue tracking, and granting power to those who just submit code, no matter if it's thought-out) is bad. I think the thing we introduced in the meantime (new problem template) was a step in the right direction, but it has issues.

I think we need to ensure we can iterate on the workflow itself. For example, I think it took too long to improve upon the first version. Going forward, I think we need to be a little faster in adjusting things that don't work well once the next version of templates are merged.

I pledge to remain responsive for the workflow. I would appreciate to get more feedback. Lack of feedback is IMHO the thing that slows this down (sometimes, weeks passed without any input about the workflow, although everyone is obviously working with it).

@mfenniak thank you for the feedback. I think the change of the process is a risk, but has significant improvement to do better. I think the traditional workflow in free/libre software development (issue tracking, and granting power to those who just submit code, no matter if it's thought-out) is bad. I think the thing we introduced in the meantime (new problem template) was a step in the right direction, but it has issues. I think we need to ensure we can iterate on the workflow itself. For example, I think it took too long to improve upon the first version. Going forward, I think we need to be a little faster in adjusting things that don't work well once the next version of templates are merged. I pledge to remain responsive for the workflow. I would appreciate to get more feedback. Lack of feedback is IMHO the thing that slows this down (sometimes, weeks passed without any input about the workflow, although everyone is obviously working with it).

@fnetX wrote in #415 (comment):

I pledge to remain responsive for the workflow. I would appreciate to get more feedback. Lack of feedback is IMHO the thing that slows this down (sometimes, weeks passed without any input about the workflow, although everyone is obviously working with it).

Wonderful. I'll provide specific feedback when I encounter any real struggles (rather than generalized skepticism). I appreciate your efforts in this area, thank you.

@fnetX wrote in https://codeberg.org/forgejo/discussions/issues/415#issuecomment-16560758: > I pledge to remain responsive for the workflow. I would appreciate to get more feedback. Lack of feedback is IMHO the thing that slows this down (sometimes, weeks passed without any input about the workflow, although everyone is obviously working with it). Wonderful. I'll provide specific feedback when I encounter any real struggles (rather than generalized skepticism). I appreciate your efforts in this area, thank you.
Sign in to join this conversation.
No Branch/Tag specified
No results found.
No results found.
Labels
Clear labels
User research - Accessibility
Requires input about accessibility features, likely involves user testing.
User research - Blocked
Do not pick as-is! We are happy if you can help, but please coordinate with ongoing redesign in this area.
User research - Community
Community features, such as discovering other people's work or otherwise feeling welcome on a Forgejo instance.
User research - Config (instance)
Instance-wide configuration, authentication and other admin-only needs.
User research - Errors
How to deal with errors in the application and write helpful error messages.
User research - Filters
How filter and search is being worked with.
User research - Future backlog
The issue might be inspiring for future design work.
User research - Git workflow
AGit, fork-based and new Git workflow, PR creation etc
User research - Labels
Active research about Labels
User research - Moderation
Moderation Featuers for Admins are undergoing active User Research
User research - Needs input
Use this label to let the User Research team know their input is requested.
User research - Notifications/Dashboard
Research on how users should know what to do next.
User research - Rendering
Text rendering, markup languages etc
User research - Repo creation
Active research about the New Repo dialog.
User research - Repo units
The repo sections, disabling them and the "Add more" button.
User research - Security
User research - Settings (in-app)
How to structure in-app settings in the future?
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
12 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
forgejo/discussions#415
Reference in a new issue
forgejo/discussions
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?