Re: [RFC] Extending project standards to services linked through Vcs-*
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.
Reply to: