Quoting Fabio Fantoni (2024-08-02 23:51:26) > Il 02/08/2024 15:49, Jonas Smedegaard ha scritto: > >> I think that both email and systems like salsa/github/gitlab etc. are > >> useful, both with pros and cons. Forcing people to use only one or the > >> other could be counterproductive at the moment. One thing that I think > >> would be useful is to have certain, fast and simple information for each > >> package about which actual collaboration methods it uses and prefers. > >> > >> For example seeing a package it would be very useful to know immediately > >> if it wants a collaboration only through bugtracker and patch, only > >> through vcs or both are accepted. If managed in a team point more easily > >> to information about the team and any pages with details (for example on > >> wiki). > > I guess that you mean something like this: > > ```patch > > --- a/debian/control > > +++ b/debian/control > > @@ -60,6 +60,7 @@ Standards-Version: 4.7.0 > > Homepage: https://github.com/oxigraph/oxigraph > > Vcs-Git: https://salsa.debian.org/debian/oxigraph.git > > Vcs-Browser: https://salsa.debian.org/debian/oxigraph > > +Contact: https://bugs.debian.org/oxigraph > > Rules-Requires-Root: no > > > > Package: oxigraph > > ``` > > > > In principle I find that an interesting suggestion, as I can imagine > > such information being helpful in understanding if debbugs is used only > > by "dinosaurs". > > > > I see two problems, however: > > > > a) Maintainers will be bothered to add that new field to every package > > (or at least a substantial subset) for it to be of practical use. > > > > b) Which other answers exist for that field? I mean, is it ok in Debian > > for a maintainer to not use Debbugs? Is it ok in Debian for a > > maintainer to also use another issue tracker and not replicate whatever > > is collected elsewhere in Debbugs? > > > > Or perhaps I am missing the point of your suggestion, and you do not > > mean where *bug* chatter goes, but instead where *non-bug* conversations > > go. If that is the case, then I believe we have a field already for > > that, called "Maintainer:". If you mean neither issue tracking nor the > > main contact information for a package, then please elaborate what you > > had in mind, because that's pretty essential to get clarified before > > discussing any further... > > > contact field don't exist now right? even if the contact field maybe > doesn't give you an idea, maybe something like "contributing" that links > to the bugtracker, to the repository MR/PR or a wiki page or site with > any details (especially in case of a group)
Yes, the contact field exists: https://www.debian.org/doc/debian-policy/ch-controlfields.html#maintainer > maybe I'm not good at explaining myself, I think the problem is that if > a contributor, maybe even new or who wants to make even occasional > contributions on specific packages is not able to find in a simple and > fast way about the package on which he wants to contribute as he should > (or is better to do), in some cases you can understand in short time by > looking a bit at the bugtracker and the vcs while, looking for any wiki > pages if he is part of a team but in many cases it is not simple/fast to > understand how he should contribute for that package in order to get the > best result. using patches on bugtracker or vcs (like salsa) is just one > part, then there could be more > > you could say to force everyone to use the same system, in theory it > would solve the problem, but in practice I find it difficult and perhaps > more harmful. I try to summarize: the contributors are people and not > machines, moreover many do it as a passion in a little free time and not > as if it were a job. We all do it as a passion in little free time and not if it were a job. Also Maintainers. What is the point of introducing additional ways to interact with maintainers than the ones that already exist and (as I understand it) is mandatory: A general contact *email* address, and tied to that a connection to the *Debbugs* issue tracker. If a new contributor is unable to contact a package maintainer through that main contact address, then I am concerned about their ability to help out. Don't get me wrong, I do understand how some people can be excellent coders or testers or translators without ever using email, but how can those who are fluent in Gitlab but unable to send and receive emails avoid being a burden in their offers for help to a software distribution which at its very core is email-based? As I see it, those maintainers in Debian - single persons or persons part of a larger team, who chooses to not only handle the mandatory communication channel of Debian, which is email, are free to act as proxies for communication at Gitlab, Matrix and whatever else, as long as they ensure that the communication is proxied (e.g. summarized) to the mandatory communication channels of Debian. It feels backwards to me to start with opening up for more channels, based on a concern for lack of free time, when effectively that is simply pushing the burden to the maintainers to invest the needed time instead. ...unless it is implied that conversations need not reach the current communication channels - which I would find problematic. [comments on wiki disregarded] > >> If someone thinks that these speed/reachabilityare not important because > >> they are used to even longer times for many operations, for example > >> regarding the bugtracker, tracker, upload etc., unfortunately we live in > >> an increasingly frenetic and continuously worsening world (this world > >> causes more and more stress and less and less time available). > > If you mean psychological stress, then I find your reasoning flawed, as > > that is about a *perceived* lack of time (or other pressure), not > > necessarily actual lack of it. Possibly but not necessarily. > > > > If you mean stress on the Earth, then I find it highly unlikely that we > > can solve that crisis by speeding things up. Instead we need to find > > ways to *reduce* the *amount* of computing we do, and find ways to time > > that computing in ways that fit more optimally with the availability of > > needed resources (e.g. consume less electricity when there is less wind > > and sunny, to reduce stress on green parts of related electricity grid). > > > > Please elaborate what kind of stress you are really talking about, and > > again please consider the topic of the conversation (see above about > > changing Subject: line). > > this is complicated to explain, I'm not good at explaining nor in english^^' > > staying on the subject of DEP-18 I think it could be relevant on stress > based on if/how it will be done and applied and what I wanted to bring > attention to is not to consider only the possible benefits on the > quality of the packages that it could bring but also the cost that it > could have on the people who contribute and try to be balanced > > it is unfortunately common to think of profit at the expense of people, > in the case of Debian it would not be for profit but the impact on > contributions can be significant. > > the ideal thing would be that it increases the quality and also makes it > more efficient and less stressful to contribute but I fear that this is > utopian and it is much more likely that there will be fewer results than > hoped for and a higher cost (on the people who contribute) Yes, this is not about money. Maintainers contribute, and should ideally not be stressed by doing so. New contributors are certainly most welcome, and should not be stressed either. And their needs should not cause stress for maintainers. Is that also what you mean, or are you only talking about the needs of new contributors here? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
