No Label
Accessibility
Agreement proposal
Communication
Election
Entrustment
Governance
Meeting
[Decision] Building proposal(s)
[Decision] Gathering criteria
[Decision] Integrating concerns
No Milestone
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: forgejo/meta#82
Loading…
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Forgejo had unique features (federation, privacy, branding, i18n, release pipeline) from the start. And work started on user research to add more and create a user centric roadmap agreed on collectively. It is a slow process that helps set expectations from Forgejo users that can be met by Forgejo contributors.
Forgejo will thrive and be sustainable by carefully chosing what matters most to its users and engaging into a develpment that contributors can complete without any stress or technical debt that will come back and haunt them later. This is the benefit of being a brand new project: it can start fresh, with a clean slate and healthy methods.
But Forgejo is not built from scratch: it sits on top of dozens of dependencies, the most prominent of which is Gitea. As a result a number of feature requests land in the Forgejo issue tracker even when they already exist in the Gitea issue tracker. And the same is true for bug reports. It is ultimately the responsibility of Forgejo to deal with these, one way or another.
In the past few weeks the issue tracker was filled with a majority of issues that do not relate to Forgejo but to Gitea. There are two kinds:
I propose that they are treated differently
Feature requests
They are new or old ideas that are not in the current Forgejo roadmap (federation, privacy, etc.). Either with an equivalent feature request in a dependency (most of the time Gitea but it could be related to a Go package).
There will always be more ideas than people available to implement them so they need to be sorted out depending on what matters most to the user. The process to do that methodically and sensibly is user research. Such feature requests should be redirected / copy pasted in the https://codeberg.org/forgejo/user-research repository to find their place in the roadmap.
Some of them may simply be redirected to the repository of the dependency (Gitea being one of them) and some may turn out to become one of the items in the Forgejo roadmap (like refactoring the User Interface).
Bug reports
They are bug reports that do not belong in the code developped by the Forgejo contributors. It belongs to a dependency but created a problem for a Forgejo user. The Forgejo contributors are accountable for:
And of course, even though it does not always happen, the Forgejo contriburors may end up providing a bug fix as well.
Because Gitea is such a prominent dependency of Forgejo and that it has over a thousand open bugs, using the same issue tracker for Forgejo bugs and dependency bugs creates a situation where the vast majority of the issues are about dependencies. This can be demotivating for Forgejo contributors who may have the impression that the codebase is not properly managed when they see a lot of open bugs with little progress. And it would make it difficult for someone reporting a bug to figure out if it is a known problem.
An important part of Forgejo being sustainable is adressing difficult problems in a sensible way. And for that to happen, it helps that there only are a few difficult bugs to fix in the Forgejo tracker. One example was the problems of the release pipeline and the CI which required weeks of work from contributors. If the issue tracker is overwhelmed by dependencies issues, it may be tempting to keep busy fixing the low hanging fruit while the main challenges are never resolved. One example in the Gitea codebase would be the lack of testing in the user interface.
The https://codeberg.org/forgejo/dependencies-bugs repository could be created and issues moved there to not clutter the https://codeberg.org/forgejo/forgejo repository. It could be done manually in the beginning and helped by a bot when and if it takes too much time.
Well described. All I want to add is that, similar to what I mentioned at the end of this Governance bootstrap comment, here exists another dogfooding situation where a need exists that can be input for User Research. Besides proposing manual procedures and workarounds there may be opportunity for product support and features on the roadmap.
After all, many FOSS projects have upstreams to deal with, and streamlining this process might be to the benefit of the FOSS movement. While git has origins to deal with upstreams, no code forge has facilities on the level of issue management and other forge-specific capabilities that make upstreaming easiest. Unique product features.. maybe. Further user research should tell, but the need is already identified.
I could imagine that forge federation helps enable an issue management workflow where regular project issues and their upstream/downstream relationships are handled without leaving the platform UI (no need to interact in remote platform of the upstream/downstream).
I'd thought about adding an issue metadata field to link to issues on the trackers of external dependencies. That alone would be a very useful addition. But @circlebuilder your suggestion about federation is simply brilliant. This would be revolutionary for projects like Forgejo where issues are often dependent on an upstream project.
I have the feeling that moving all the dependency bugs to another repository would have the same effect as having them marked upstream and closed in favour of another location. What will be the criteria for categorising between low hanging fruit bugs and difficult bugs?
And what will be the criteria for downstream bugs, that whole set reported to Codeberg that Forgejo is going to be upstream? All that set are from Codeberg users, future Forgejo users.
A few days ago some user came to the chat with a case that @Gusted solved very quickly, but it took months to find out the real problem behind it. This kind of work could get out of the forgejo repository with this bug forwarding policy, but it's a good case of a well done task that left the user satisfied and makes human interaction synergistic.
I would be very careful about promoting difficult contributions in favour of small ones, because small ones produce much more user satisfaction and provide much more interest in being involved with the project. I tend to believe that the opposite is a developer-centric view rather than a user-centric view.
Gitea has a good number of outstanding bugs and the risk of inheriting that set as technical debt is very high, but at the same time, it is an opportunity to gain satisfaction from the whole user community in favour of Forgejo.
That depends. For instance if an LDAP bug is found and turns out to be a bug in the go package that implements ldap (which Gitea depends on), it will be good to keep an eye on it. But it is reasonable to wait for the author of the ldap package to fix that, unless it is blocking.
It could. But I think Forgejo contributors can be trusted with their best judgement to not do that.
I also trust Forgejo contributors common sense to find the right balance. Not overlook difficult contributions that are the unique responsibility of Forgejo. And not overlook easy fixes that are satisfying for both the user and the developer.
I don't understand this response. I probably explained wrong. I thought in a case with an already forwarded issue that has been resolved later, in the new
dependencies-bugsrepository (the case used as example was first reported days before in Codeberg). My concern is about the separation between resolved issues, because that kind of contribution will be de-articulated with the others, the Forgejo ones.Ok. Thanks for respond.
The issues will be separated indeed. And it may cause problems as you describe. But it also has advantages. If the issues are not separated it is very difficult to find the Forgejo issues: there are many more non Forgejo issues.
Does that make sense?
@caesar as part of earlier promise to explain how Social Coding fits with Forgejo, I documented my thoughts on the movement, and gave this issue as an example to work on. I will add a comment to Consider to be a Social Coding practitioner (#14) where this relationship can be further discussed.
Not much, but not because I don't see the challenge. If I understood correctly, the problem is the poor filtering capabilities of the issue manager, which lacks, for example, predicate negation. If that is the case, another solution is to provide a label to Forgejo issues. Because the main bad consequence I see with issue movement is that we wouldn't see how many kind-ui issues there are, upstream or not. Or, worse for me, how many a11y issues there are in Forgejo, including those opened in new branches (not today, in the future). Or filtering by users to measure contributions or issue reporting, etc. That is, looking at Forgejo issues as a whole, for example for someone who is going to make the decision to use it or not. For that kind of decision, it doesn't matter if the issues are from your dependencies or not. It is also a matter of transparency.
I see no mention of this drawback in the proposal - are we aware of it?
This is probably just a drawback for me
To illustrate the challenge, here is an example. Who among the current Forgejo contributors is going to work on all existing features requests and all bug fixes? You are involved daily with Forgejo, can you figure out which one are most important? And can you make a guess as to how many of them are going to be implemented in the next month?
Maybe splitting the issues and feature requests into separate issue trackers is not the solution. But I think we all agree there is a problem with the inflation of bug reports and feature requests and that needs to be adressed now: it will only get worse as time passes if nothing is done.
I think you misunderstood me @dachary. I shouldn't have used the double negative, it tends to lead to misunderstandings. Please excuse me.
I think at least we have an agreement about the challenge.
Indeed... I misread the double negative, sorry about that 😇 Please ignore my last message.
While this discussion is ongoing, I'd like to mention a reorganization of the labels that is relevant. It helps separate which issues/pull requests are the unique responsibility of Forgejo contributors from those that have an impact on Forgejo but are ultimately the responsibility of a dependency (Woodpecker CI, Gitea, etc.).
It feels like the main bottleneck here on actually doing this smoothly is going to be the metadata we can store in the issues system.
A priority system, an system to order items and more status' will be the obvious ones, not sure if gitea's upgrade in the area of projects/milestones touches upon that. An existing issue by moi here; Codeberg/Community#694
If those basic buildingblocks become available, it would be much simpler to handle things talked about here and on the ui-research project.
The above rant is based on my impression that adding upsteam issues is going to create user interface issues. Specifically users are going to find it hard to filter for what they want or need.
Same with the idea of the wish for the UI team to help select needed things. We only really have tags for this and thats not going to be very user friendly.
The direction I proposed in the description of this issue is evidently a deadend. I'll close this issue, not because it is solved but because it is stuck for reasons that are difficult to figure out. The problem still exists but will most likely benefit from starting fresh, with a new issue authored by someone with a different viewpoint than mine.
I don't have time to gauge that now. But closing unresolved issue makes the discussion be for naught. They might be closed to clean the backlog, but maybe they need a label to them as reminder to revisit later.. or keep them open for a bit and parse the useful bits into a new issue.
@circlebuilder if I understand correctly you have issues about how I proceed with this issues and others. It is healthy to have a debate on that topic but maybe having it here is not the best place. Would you care to open an issue on the matter?
As for this particular issue I stand by the rationale I took the time to explain for closing it and I'm ready to discuss its relevance when you have time to look at it.
No, it is about this particular issue. It is not a dead end, as it led to forgejo/user-research#9 and this issue can be seen as user feedback (in this case of those that happen to work on Forgejo as well, but it is a problem many FOSS projects face. Which I mentioned above). By closing we may overlook that.
I'll reopen then.