Il 24/01/2025 15:26, Christoph J. Scherr ha scritto:
If we want to continue to use mainly BTS I think you should have an integration with something that allows you to do more things from the web interface, in a simple and fast way.On Fri, 2025-01-24 at 13:05 +0100, Jonas Smedegaard wrote:Hi Christoph,Quoting Christoph J. Scherr (2025-01-24 12:13:16)Hello, As someone just starting out with Debian, I'd like to share my perspective on this discussion. I only recently contacted the welcome team and have been following the mailing lists while waiting for my salsa account approval. From what I've seen so far, Debian's development process can be quite challenging to understand as a newcomer. In my opinion, having a more intuitive web interface through a code forge like GitLab would lower the barrier to entry for potential contributors. I believe that normalizing merge requests would particularly benefit contributors from younger generations, who are more familiar with these modern development workflows. Exploring the BTS is, for me at least, more confusing for me than exploring a git repository with issues and merge requests on salsa. This is my first email to the lists. I hope these thoughts are relevant and helpful to the discussion.Welcome! You certainly make a relevant point, and I believe that I understand how that point is central for this discussion. What troubles me, however, is if that is the only point deemed central to this discussion. Yes, it is easier to use tooling that we are used to. Yes, it helps collaboration around our preferred tooling if user interfaces are as user friendly as possible. I think we can all agree on that, in isolation. I think we can also all agree, that the BTS is not as globally familiar as Github issue tracking facilities, nor as pleasing and welcoming and intuitive to use especially for people oriented towards web interfaces. I don't challenge any of those observations - I agree with them. What I have a problem with is collaboration optimized *only* towards the needs of newcomers. I find the BTS highly valuable *despite* it being unwelcoming, not because I come from a different time where its design is somehow a bliss to work with. I find non-webby git interactions highly valuable *despite* it being less intuitive than web-based user interfaces and workflows. We each have a comfort zone, and an understanding of benefits and qualities of the tooling we are familiar with, and when we engage in collaboration we may get challenged about that. But finding the ideal ways to collaborate is a complex assessment, not one that benefits from reducing the options to a binary "does it raise the bar for newcomers?" question, in my opinion. I would love to collaborate with you, but when our ways of working are different, I would like to look at how our different toolings are helping each of us (the comfort zones of you and me), our product (the packages etc. that we are working on concretely) and our project (how our ways of working may affect others in Debian). It feels to me that this conversation reduces that conversation to "what is best for newcomers is best for Debian" and I am not convinced that that is a sensible reduction. Hope that makes sense. - JonasHello Jonas, I did not mean that the BTS has no value. Quite the opposite in fact: Without a method to trace bugs globally, there would be chaos. This is a complex topic, I just wanted to add my stance on this particular point. Writing a Pro/Con list might be a good idea, but I am not proficient enough in both the BTS and GitLab to do so. Greetings Christoph
I recently saw this project that seems good to slightly improve some things, for example: https://fabre.debian.net/
Talking about salsa it comes to mind that it could be used for authentication if the possibility of doing operations from the web on BTS (if will be added), therefore keeping the opening of bugs via the usual tool or via email, renewed navigation in bugs and the possibility of responses and operations both in the old method via email and from the web. Among the functions that can be added, perhaps it could be to connect more easily to any MR in the repository. Add more default links, to make it easier and faster to reach the packaging repository (if present), the upstream repository (from upstream metadata, if present) and possible others. It has been useful to me in many cases (and it will be useful again), it may seems not be very useful but having some things more at hand and also being able to reach some parts by making a few less clicks and changing tabs when perhaps you end up doing such operations a few hundred or thousand times a year no longer seems like a useless or insignificant advantage.
What do you think?
OpenPGP_signature.asc
Description: OpenPGP digital signature
