Hi Dominik You proposal looked reasonable, yet at the same time something seemed to be off.
After some pondering, I think it may be going for the wrong problem. 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? (*) 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. 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) *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. Best regards (*) You mention > two of the rather problematic ones including using a VCS, and then > frowning upon contributions outside the VCS, and using a VCS, but > then not allowing contributors to use the VCS as well but these would still be possible.