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