Re: [RFC] Extending project standards to services linked through Vcs-*

[Dominik George]

Hi,

> As an aside, unless something has changed very recently, GH does not
> give you a way to disable PRs (issues yes but not PRs).
> 
> If that has suddenly become possible, I have around a thousand
> projects I help maintain upstream on a non-GitHub (open source) code
> forge and would love to have a way to disable PRs on all the GH
> mirrors of those. For now we run a periodic bot that scans for open
> pull requests and closes them with a comment telling people where to
> find our contributor workflow documentation.

Thanks for the hint!

You are indeed right – disabling pull requests is not possible on GH.

In any case, making it prominently clear that pull requests are not
the primary way of contribution, would be sufficient for the case in
point.

-nik


signature.asc
Description: PGP signature

Re: [RFC] Extending project standards to services linked through Vcs-*

[Russ Allbery]

Dominik George  writes:

> Hi,

>> have you considered dgit?

> no, as that's something entirely different. dgit does not
> manage source packages in Git, it provides a Git frontend
> to source packages not managed in Git.

No, this is not really true.  There's a lot of misunderstanding about
dgit.  It does in fact manage source packages in Git.

You are thinking of the use of dgit for packages that don't use dgit in
their upload flow.  In those cases, yes, dgit creates a synthetic Git
repository that only includes one commit per upload to Debian.  Better
than nothing, but not really managing the source package in Git.

However, if one uses dgit in one's upload flow, all relevant Git changes
are pushed to the dgit Git repository.  You can close the dgit repository
and get exactly the Git repository that the package maintainer used to
develop and upload the package, just as if you were using a Git forge.

Obviously, dgit doesn't have the other functions of a Git forge, such as
issue tracking, CI, or merge requests.  But it does manage source packages
in Git.

-- 
Russ Allbery (r...@debian.org)  

Re: [RFC] Extending project standards to services linked through Vcs-*

[Russ Allbery]

Dominik George  writes:
> On Mon, Aug 21, 2023 at 09:48:26AM -0700, Russ Allbery wrote:

>> This implies that Salsa is happy to create accounts for people under
>> the age of 13, since the implicit statement here is that Debian's own
>> Git hosting infrastructure is less excluding than GitHub.

>> That's a somewhat surprising statement to me, given the complicated
>> legal issues involved in taking personal data from someone that young,
>> so I want to double-check: is that in fact the case?

> That is, in fact, the case.

> And no, it's not not legally complicated to collect personal data from
> children. If we, for now, only look at COPPA and GDPR, the laws relevant
> for the US and EU, respectively, the situation is:

[...]

Thank you!  This is good to know and I'm very happy that this is the case.
I'm glad people have done the research that I hadn't done and worked out
what was required!

-- 
Russ Allbery (r...@debian.org)  

Re: [RFC] Extending project standards to services linked through Vcs-*

[Dominik George]

Hi,

> have you considered dgit?

no, as that's something entirely different. dgit does not
manage source packages in Git, it provides a Git frontend
to source packages not managed in Git.

-nik


signature.asc
Description: PGP signature

Re: [RFC] Extending project standards to services linked through Vcs-*

[Dominik George]

Hi,

On Mon, Aug 21, 2023 at 09:48:26AM -0700, Russ Allbery wrote:
> Dominik George  writes:
> 
> > For the GitHub case, the problematic terms would be that in order to
> > register for a GitHub account, users must be at least 13 or 16 years old
> > (depending on the jurisdiction) ant must not live in a country under US
> > embargoes.
> 
> This implies that Salsa is happy to create accounts for people under the
> age of 13, since the implicit statement here is that Debian's own Git
> hosting infrastructure is less excluding than GitHub.
> 
> That's a somewhat surprising statement to me, given the complicated legal
> issues involved in taking personal data from someone that young, so I want
> to double-check: is that in fact the case?

That is, in fact, the case.

And no, it's not not legally complicated to collect personal data from
children. If we, for now, only look at COPPA and GDPR, the laws relevant
for the US and EU, respectively, the situation is:

 * You can accept consent from children, if:

   * it can be, objectively, assumed that they can overlook the
 consequences of the data collection
 → we can assume that, if someone sucessfully contributes to
   a Debian package, they are knowledgable enough, given that
   Salsa only collects a pseudonym and an e-mail address

   * you don't use the data for marketing or profiling purposes
 → we don't do that

   * you don't direct commercial advertisements at children
 → we don't do that

   * you don't explicitly advertise your service to children
 (as in, promising them a benifit exceptionally attractive for
 children)
 → we don't do that

Even if we did one of the above things, we'd still be able to accept
children if they have parental consent, which is a bit tricky (but,
should we get to this at some point, be outsourced to a trusted partner,
like Teckids, who has expertise in that field). If we get to this point,
I will certainly fight to accept children with parental consent, even
if it implies some work. GitHub and a lot of other services, however,
in addition to not being able to allow children without parental
consent, also don't accept them *with* parental consent.


As it stands, Salsa (and a lot of other Debian services) are not
GDPR-compliant because they do not have a privacy statement making the
above clear, but while related, let's not mix that into this thread.


Cheers,
Nik



signature.asc
Description: PGP signature

Re: [RFC] Extending project standards to services linked through Vcs-*

[Russ Allbery]

Dominik George  writes:

> For the GitHub case, the problematic terms would be that in order to
> register for a GitHub account, users must be at least 13 or 16 years old
> (depending on the jurisdiction) ant must not live in a country under US
> embargoes.

This implies that Salsa is happy to create accounts for people under the
age of 13, since the implicit statement here is that Debian's own Git
hosting infrastructure is less excluding than GitHub.

That's a somewhat surprising statement to me, given the complicated legal
issues involved in taking personal data from someone that young, so I want
to double-check: is that in fact the case?

(US embargoes are indeed going to be a problem for any service hosted in
the United States, and possibly an issue, depending on the details, for
any maintainer with US citizenship even if they're using a site hosted
elsewhere.  I would not dare to venture an analysis without legal advice.)

-- 
Russ Allbery (r...@debian.org)  

Re: [RFC] Extending project standards to services linked through Vcs-*

[Holger Levsen]

hi Nik,

On Mon, Aug 21, 2023 at 05:00:04PM +0200, Dominik George wrote:
> Generally, not having a clear policy on that VCS package maintenance means
> is, in my opinion, one of the major obstacles when trying to contribute
> to Debian.
[...]

have you considered dgit?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The past is over.


signature.asc
Description: PGP signature

Re: [RFC] Extending project standards to services linked through Vcs-*

[Jeremy Stanley]

On 2023-08-21 17:00:04 +0200 (+0200), Dominik George wrote:
[...]
> A concrete implementation for GitHub repositories would be to
> disable issues and PRs
[...]

As an aside, unless something has changed very recently, GH does not
give you a way to disable PRs (issues yes but not PRs).

If that has suddenly become possible, I have around a thousand
projects I help maintain upstream on a non-GitHub (open source) code
forge and would love to have a way to disable PRs on all the GH
mirrors of those. For now we run a periodic bot that scans for open
pull requests and closes them with a comment telling people where to
find our contributor workflow documentation.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

[RFC] Extending project standards to services linked through Vcs-*

[Dominik George]

Heisann,

[ for reference, the general discussion was held in 2019 already, in a slightly 
]
[ too big context [3].  
]

as many of you will know, I am heavily involved in tearing down obstacles
in the way of contributing to free and open source software (with a focus on
very young people). As a Debian Developer, I am proud to use and contribute to
a distribution that is among the top projects in that regard, by…

 * …depending almost purely on its own infrastructure
 * …not caring the least about any personal attributes of contributors
 * …having policies in place that are (legally) acceptable by virtually
   everyone, only limited by legislation, if at all
 * …putting great freedom in the choice of tools into the hands of
   contributors
 * …actively fostering education and young people

However, there is one aspect I sometimes find to cause a break in this
outstanding pattern: The ever so often discussed maintenance of source
packages in (Git) repositories (for the sake of simplicity, I am ignoring
non-Git VCSs here).

Basically, as a quick summarization, the rules for VCS usage are:

 * Maintainers are free to use a VCS for packaging, or not
 * Maintainers are free to choose any VCS they like
 * VCSes can optionally be linked to source packages through the VCS-*
   fields [1]
   * Policy somewhat requires VCSes that are linked in VC-* fields in
 source packages to be pblicly accessible
 * Maintainers must use the official contribution channels (i.e. the BTS)
   even if they use a VCS [2]

In essence, we could, somewhat polemically, conclude that:

  Packages may be developed in a VCS repository for the maintainers'
  delight, but these repositories are not an official part of the
  package lifecycle from a distribution perspective

Generally, not having a clear policy on that VCS package maintenance means
is, in my opinion, one of the major obstacles when trying to contribute
to Debian. Part of this is the freedom maintainers have in using these
tools. This results in variosu different approaches, 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.

In contrast to the huge discussion in 2019, I would like to propose a softer
set of policies to tackle this problem, with the ultimate goal of allowing
collaboration for everyone indeendent of whether a VCS is used or not.


Besides the social challenges that come with maintainer decisions, the
measurable aspect is whether contributors can collaborate on the VCS or
not, if they want to and if the maintainer generally accepts contributions
there.

For the current picture, here is a summary of where VCS repositories linked
to source packages are currently hosted:

   Debian infrastructure   181969
   GitHub.com3898
   GitLab.com 334

A full ranking of the VCS hosts can be acquired using UDD with a query like

  select substring(vcs_url from '(?<=://)[^/]+(?=/)') as domain,
 count(vcs_url) as count from sources
 group by domain order by count desc;


The issues with GitHub as an example were discussed from a freedom perspective
in 2019 in a sub-thread [4] – the essence being "GitHub is non-free, noone 
should
hae to use non-free services to contribute to Debian".

Instead, I'd rather like to examine the situation from an equlity perspective,
and from a perspective of extending the general tenor of DFSG (in particular,
point 5) [5] to other terms besides licenses. For instance, that would be:

  "The terms of use must not discriminate against any person or group of 
persons."

The essential doctrine would be that we, as the Debian community, must not 
impose
any limitations on who can contribute, in addition to those potentially imposed
by governing laws, and that we must ensure that all people that can participate
at all can do so under the same preconditions.

For the GitHub case, the problematic terms would be that in order to register 
for
a GitHub account, users must be at least 13 or 16 years old (depending on the
jurisdiction) ant must not live in a country under US embargoes.


Now, some will argue that it's still optional to use the VCS, and that anybody
who wants to contribute to a package can unconditionally do so using the BTS,
even if the maintainers use a VCS repository. That would, of course, require
a stric policy placing all maintainers under the obligation to accept 
contributions
through the BTS, even if they use a VCS.

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.


Now for the concrete implementation of this idea: I propose to