Hi Dominik On 2023-08-30 at 11:04 +0200, Dominik George wrote: > > 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.
Pushing *everyone* to use the VCS instead of the BTS does not "discriminate on who is invited to contribute through the VCS". Particularly if such VCS has no intrinsic bias about who may use it. It does violate the "and you must also allow contributing through BTS" rule, but that must be a separate one. > 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. In my view, this is precisely a case of "the people don't know the accepted/preferred way to contribute" > However, pull requests were accepted on GitHub, which fulfills my > description of "being invited", If other random people had pull requests that were being discussed or even merged, then I would consider it a sign that they were accepted. If it's just a project with zero pull requests and you mean there's a GitHub button, then I don't think it can be considered an invitation by the maintainer. See the Jeremy case. GitHub UI shows such an option but PR are not actually accepted on GitHub. > and GitHub having exclusive terms also of "other being not invited". This may be an important difference. I am only considering choices made by the maintainer. Not by the VCS hosting or their upstream ISP. If GitHub were blocking access from Russia [1] *and the maintainer chose GitHub so that Russian couldn't contribute*, I would consider that discriminating. If the maintainer is not aware of that, they are not being discriminated _by the maintainer_ (indirectly, they would still unable to access it, anyway)- Interestingly, it might even happen that *nobody* wanted to discriminate the target of a block, such as a firewall rule overly inclusive, or a block based on an outdated atabase. [1] They are not: https://github.blog/2022-03-02-our-response-to-the-war-in-ukraine/ > 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. Ok. I misread your statement as covering actions/choices by the maintainer, not by the platform. I think this would be more clear if stating the properties that such VCS would need to have (e.g. not requiring a minimum age), both Debian- based and external, rather than just saying "the same conditions as the Debian BTS" > 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. I completely agree with that. Regards
