Hello all,
Reading a random fediverse thread, I came across some aspects about
growth of issues and governance around duplications and feature
requests:
https://social.wildeboer.net/@jwildeboer/114131748974841455
```
What I gather from the replies is that better issue tracking should work
with at least 3 separate queues:
- Bugs (things that don't work as they should, breaking functionality,
can be fixed relatively fast)
- Feature requests (Things that don't exist yet in the codebase but
could be added)
- Refactoring (Things that can be bugs or features, but to solve them a
redesign/rewrite/refactor of certain parts of the codebase is needed)
Triage should decide where a new issue belongs.
```
https://social.wildeboer.net/@jwildeboer/114132897616035930
```
often issue trackers are used for feature requests. I think it is
reasonable for those to stay open for long-ish periods of time as part
of a long term roadmap or a help-wanted list. I agree those should be
clearly distinguished from bugs, but sometimes the line between "missing
feature" and "bug" blurs.
```
https://kolektiva.social/@cscott/114132771181298941
Is there a need to provide more formal clarifications regarding
collective expectations and emphases?
Are there any case studies we are using to inform such outcomes?
In particular, is there anything distinct to the Guix experience that we
need to be mindful of?
Kind regards,
Jonathan
On 2025-03-07 06:18, Divya Ranjan wrote:
Hello Carlo,
I don't think this is a fair summary of the goal. The first sentence
of
the GCD[1] is:
The contribution workflow in Guix has been facing several
challenges:
difficult onboarding, lack of legibility, complex, unreliable, and
labor-intensive infrastructure, and lack of automation.
Of these, only "difficult onboarding" is about newcomers. Your
proposal
(which I might describe as "proxy Codeberg into debbugs") involves
building new infrastructure without helping the other issues.
You are correct, Carlo, the GCD does have multiple goals. But in my
email I also elaborated how the onboarding issue is a high-priority
task, reflective from the last survey and also something that can be
achieved without risking too much. I believe we are at a probabilistic
trade-off decision here, do we wish to achieve all the goals, including
a complete change of infrastructure, workflow etc. in the proposed
timeline of 15 days or so, and thus incurring a lot of problems that a
team of committers would’ve to put a lot of effort into resolving? Or,
do we wish to slowly achieve some of the goals, take those goals as a
litmus test for the overall proposal and proceed gradually? I believe
latter would be a safer bet, with less to risk immediately and
opportunity to fix mistakes from feedback.
So, yes, my proposal cannot resolve all the goals, but I am trying to
find a way to integrate what we have with what we might switch to. I
might be at fault here, and feel free to elaborate on that, such as how
can we approach the proposed quick migration to Codeberg while having a
huge backlog of patches?
Since Codeberg already allows to communicate in issues over email,
i.e. you can respond to someone in a particular issue over email,
this
shouldn’t be too difficult to arrange.
This is not true today. While Forgejo supports replying via email,
Codeberg does not have that enabled due to bugs. They have an issue
tracking it: https://codeberg.org/Codeberg/Community/issues/1562
Thank you for this. I had tried it on a Forgejo repository, not a
Codeberg one, so I believed the same could be possible here as well.
From the discussions I see, if we spend enough time with them--which we
need to do either ways--for the migration, they might get it working?
Does not look far from possible to me.
Even if it was true, the big disconnect here would be around
commenting
on specific lines of code. An email with a comment on a patch would
come
through as a top-level comment on the PR, which is not natural in that
context.
Also thank you for bringing this issue, indeed this is a crucial
functionality. But to be clear, this is specifically for a
pull-request. The issues functionality is totally doable out of the box
with Forgejo, we just need to make it work with Codeberg and polish it.
With regards to the PR, one has to remember that the entire process
needs to be wrapped around Forgejo’s API, not as our used to method of
plain text. We’d be parsing JSON to-and-fro. For "reviewing a Pull
Request" in Codeberg methodology, Forgejo provides a
=/repos/{owner}/{repo}/pulls/{index}/reviews= API[0] to initiate a
review. This API will take the comments from the patch in the Email,
place them in the "body" string of the JSON, and the respective
positions from the diff, the commit_id and so on. I agree it is
non-trivial, but so is switching a workflow that has been in-place for
years, also a non-trivial task. I think the API has enough things for
what we need. And again, we don’t need all of them, we only require
implementing those for now that bridge existing email workflow and the
newcomers’ onboarding. Merging, for example, I propose to be done in
the usual way of taking a patch and applying it. Eventually once we
have less of a backlog, and more ease of migration, one might consider
moving these core tasks to the Codeberg as well.
Either ways, we are at the crossroads and we need to decide which
trade-off is worth the pain. I believe it is *not* certain that once we
entirely migrate to Codeberg, the goals of "complexity" and "lack of
legibility" would be immediately reaped. It creates a possibility of
enjoying them, but given the assumption that the switch from existing
architecture is smooth. And, once again, if we were a relatively
smaller project such as the Guix-Science, this could’ve been a decision
much simpler and with less at stake, but that is not the case. But I
think it *is* certain that if we take an approach that doesn’t directly
replace one workflow with another, but bridges the new one with the
previous one, the committers will have a better way to switch. Simply
because they can try to finish the backlog using the existing workflow,
and the new patches can come to them with that as well. Where we go
from there, can be decided upon how good the litmus test goes.
[0]: https://codeberg.org/api/swagger#/repository/repoCreatePullReview
Regards,
