Hi Ángel, > On 2023-08-21 at 17:00 +0200, Dominik George wrote: > > But, I want to go one step further and think about who is invited to > > do what. If *some* people are invited to contribute through the VCS, > > and others are not, this does not fulfill the requirement of > > equality. So, if we invite one person to contribute through a VCS > > platform, we should invite everyone to do so. > > Is this really an issue? > > These terms make perfect sense but, isn't everyone pretty much doing it > already? Are there cases where *some* non-maintainers are invited to > contribute through the VCS while others are not? (*)
Yes, my proposal is based on two very specific encounters, where contributors were more or less pushed to use the VCS instead of the BTS. I was myself in another case where I wanted to contribute to a package and found out that it is maintained on GitHub, but I did not get to find out whether I could have contributed without using GitHub. However, pull requests were accepted on GitHub, which fulfills my description of "being invited", and GitHub having exclusive terms also of "other being not invited". So yes, it is a real issue, albeit a corner case. > Rather, I think the problem statement would be that people don't know > the "right way to contribute" to the package. > > Some maintainers will prefer the BTS. > Others will like to receive patches against the VCS. Or pull requests. > Against the master branch. Or main. Or devel. None of them, against the > last stable. > The maintainer may internally use GitHub issues. Or a Launchpad > project. Or use any of many other systems to track issues. > > > Not knowing the procedure. [for this specific package] → Trying to > contribute in some way that seemed appropriate → Turns out it isn't → > Failure. That's not the problem at hand. The problem at hand is where the maintainer thinks the "proper" way is using the VCS, and chooses a VCS that is less inclusive than Debian systems. It does not help to tell the contributor that the VCS is the proper way to contribute, because they cannot use it. And that's exactly what I would like to prevent. > A typical case would be a maintainer which has no problem accepting > contributions through GitHub. It just happens not to notice issues > opened there (yet contributors think they did what was expected), and > checks them only once a year. > For the argument's sake, let's suppose that the maintainer reviews theGitHub > issues and pull requests on New Year's Eve, processing everything opened in > the last year, by anyone. > > It doesn't break the equality terms. Everyone contributing through > GitHub is treated the same. But it is nevertheless a Bad experience. > > (It may be that "maintainers must ensure that the VCS is accessible > under the same conditions as the Debian BTS to anybody" was expected to > cover "They must look at issues opened in GitHub as often as they look > at the BTS" as well? It's nt clear what "under the same conditions" was > trying to cater) I don't think that's part of the argument. My request does not make any assumptions on how often and when and why a maintainer handles contributions. It only asks for offering the same access conditions to the used platforms to everyone. > > > *Disabling* the embedded VCS means for contribution is one way to > signal it's not the expected way, but only incidentally. > > > I don't know what would be the proper way to mark the expected way to > contribute. Ideally, a good old "CONTRIBUTING" file, but that might be > considered too cumbersome and barely followed. Adding a field listing > the preferred (or allowed) way to contribute would do, but that would > mean adding yet another field. Well, the consequence of my proposal, if we take it further, would be: If a maintainer lists their VCS in the source package, then they need to accept people using it. And if they accept people using it, they must ensure that everyone can do so under the same conditions. Maintainers of course MUST always accept bugs and patches (accept as in receive and consider, not merge into their package) through the BTS. We have this provision in place, and I have no intentions to change that. -nik
signature.asc
Description: PGP signature
