[gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

A question I'd like the candidates to answer.

What do you feel that Council can do to increase the contributions to
Gentoo?

- how do you feel development velocity of Gentoo should be measured?
- how do you feel technical debt of Gentoo should be measured?
- how do we make it easier to get orders of magnitude more contributors?
- how do we make it easier to do QA on significantly more contributions?
- what blockers do you perceive in the contribution processes, and how
  do you think they should be tackled?

Many of the developers I nominated in my previous email to the -project
list were because are the very prolific contributors or have significant
impact in their contributors: how can we increase not just the prolific
contributors, but get many more contributors everywhere?

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[Matt Turner]

On Thu, Jun 16, 2022 at 2:06 PM Robin H. Johnson <robbat2@gentoo.org> wrote:
> A question I'd like the candidates to answer.
>
> What do you feel that Council can do to increase the contributions to
> Gentoo?

Continue encouraging tooling improvements. Our tooling has improved by
leaps and bounds in recent years:

- app-portage/iwdevtools for all kinds of useful QA checks
- app-portage/gentoolkit's merge-driver-ekeyword for automatically
handling rebase conflicts in KEYWORDS
- app-portage/mgorny-dev-scripts for lots of useful scripts
- app-portage/nattka for stable and keyword requests
- app-portage/pram for applying GitHub PRs
- dev-util/pkgcheck for static analysis checks

In the same vein, we need to deprecate inferior tooling (like I
proposed and Council approved with app-portage/repoman). Too much time
is wasted correcting mistakes that e.g. repoman doesn't catch that
pkgcheck does. Too much time is wasted fixing mistakes that would have
been caught with pre-push CI (that Gitlab could provide in the
future).

But we still would stand to benefit from other improvements. I'd like
to make a tool that emails maintainers monthly with a summary of
things like

- list of maintained packages that have newer versions available
- list of maintained packages that are ready for stabilization
- list of bugs assigned to the maintainer
- maybe something about the last time the maintainer touched a
particular package

I think this would go a long way to resolving some issues I've seen in
Gentoo, where developers don't remember that they are the maintainer
of a package, or they don't notice that there's a newer version
available, or that it's time to stabilize one of their packages, etc.
These situations often end up blocking the work of more proactive
developers.

> - how do you feel development velocity of Gentoo should be measured?
> - how do you feel technical debt of Gentoo should be measured?

I don't think the answers to either of these questions is particularly
instructive.

For development velocity, I guess https://www.openhub.net/p/gentoo/ is
at least interesting—particularly the number of contributors ("Up + 28
(4%) from previous 12 months").

> - how do we make it easier to get orders of magnitude more contributors?

I don't think aiming for order-of-magnitude increases in contributors
is a realistic goal. We've been within ±10% of 200 contributors
(according to the OpenHub data) for the last 5 years.

Gaining contributors is important though, and I think the most
significant thing we can do here is to foster a community that people
enjoy being a part of. The last few years has seen an exodus,
voluntary and otherwise, or some rather antisocial characters. I think
Gentoo is significantly more fun as a result.

> - how do we make it easier to do QA on significantly more contributions?

Gitlab. See below.

> - what blockers do you perceive in the contribution processes, and how
>   do you think they should be tackled?

Getting Gitlab going on Gentoo's infrastructure is in progress, and I
have high hopes for it to provide significant benefits—including
reducing the barrier to entry for contributors; at the same time I'm
concerned about our infrastructure team's capacity to support it.

Generally speaking, my most significant concerns about Gentoo are
related to the infrastructure team's capacity to handle issues that
only it can handle (or has permissions to handle). There are many
ideas for improvement and/or requests that have languished for years.
A few that come to mind from the top of my head:

- Forums migration (was brought up as a potential blocker to doing
something about the Off The Wall forum during Council discussions in
December 2020)
- Distfiles hosting (bug #176186, opened April 2007)
- Allow retirement team to process retirements without infra
involvement (bug #311511)
- Various packages.gentoo.org bugs
- Setting up the new $25k servers Council approved
- Integration with RelEng processes is a pain
- Gitlab + CI
- Something needed for the new glsamaker?
- Probably more I've forgotten

It's just generally difficult to get infra to do almost anything in a
timely fashion. I don't know what Council can do to resolve this
situation other than to highlight it as a problem.

Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[Michał Górny]

On Thu, 2022-06-16 at 18:06 +0000, Robin H. Johnson wrote:
> A question I'd like the candidates to answer.
> 
> What do you feel that Council can do to increase the contributions to
> Gentoo?

There's actually very little that Council can do, as a body.  It's
something *we all* have to do, and Council's role here should be mostly
to provide the necessary support and guidance when it's required.

This is a really broad topic, so I'm going to try to keep it short:

1) Continue making a great distro.  Let's be honest -- if people don't
find using Gentoo beneficial, we can't expect them to stay around
and contribute.

2) Make contributors feel appreciated.  This is open source, the most
people can really expect from contributing is satisfaction.  If they
don't feel their contributions are helpful and appreciated, they won't
be contributing for long.

That's just a start but with these two points satisfied, things are
going to steadily improve.

> - how do you feel development velocity of Gentoo should be measured?
> - how do you feel technical debt of Gentoo should be measured?

I can't really answer these questions unless you define what is the goal
of measuring these.  Without putting the measures in context, they'd
only be meaningless numbers.

> - how do we make it easier to get orders of magnitude more contributors?

We've already solved that via GURU.  In my opinion, that's the best
thing since Sunrise, with the extra feature that we've learned from
Sunrise and designed GURU to be self-sustainable.

We've made a place where people can freely contribute, work together
and be satisfied with being able to share their work with more Gentoo
users than before.  At the same time, they can learn more, improve their
skills and eventually become Gentoo developers — and we get that almost
for free which means we can focus more on making Gentoo a great distro
and working with people who are ready to take the next step.

> - how do we make it easier to do QA on significantly more contributions?

Again, this is in large part done thanks to pkgcheck.  I mean, we
finally have a proper QA tool that's easy to use and fast enough.  I've
recently tried it on jiji, and pkgcheck was able to do a full ::gentoo
scan in 1.5 min!

The next step is replacing the antiquated CI tooling with something more
sustainable; most notably, not relying on humongous git repos to
transfer data around.

> - what blockers do you perceive in the contribution processes, and how
>   do you think they should be tackled?

In my opinion, the biggest blocker still remains developers' time.  We
can't expect to meaningfully get more contributions if we can't
realistically merge them.  Trying to take our more than we can handle is
only going to result in frustration among potential contributors,
and in the end it's going to be a loss to Gentoo.

This is also why we shouldn't be aiming for "orders of magnitude more
contributors" -- we should be aiming at steady-but-slow increase
in contributors, and the new contributors will be able to onboard even
more contributors.

-- 
Best regards,
Michał Górny

Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 5943 bytes --]



> On 16 Jun 2022, at 19:06, Robin H. Johnson <robbat2@gentoo.org> wrote:
> 
> A question I'd like the candidates to answer.
> 

I think mgorny's point about the questions is spot on -- they're not bad ones at all,
but they need the whole community to engage on them (so I hope non-nominees
might engage too). Council can't dictate things, and a lot of these aren't
within its gift, but it is of course important to know what we feel is important.

All that to say, I hope it prompts a discussion from all corners of the community,
not just candidates.

> What do you feel that Council can do to increase the contributions to
> Gentoo?
> 
> - how do you feel development velocity of Gentoo should be measured?

> - how do you feel technical debt of Gentoo should be measured?
> - how do we make it easier to get orders of magnitude more contributors?


I've been trying to spend a lot of time on mentoring new developers and it's
worked pretty well, I think: https://dev.gentoo.org/~mgorny/gentoo-family.svg.

The problem is, I can't do everything (nor do I want to), and while more contributors
actually helps reduce workload in the long run, it still requires some up front
effort.

I worry a bit about how most developers don't seem to end up mentoring
either many or in a lot of cases, anybody at all. It's totally okay not to -
not everybody enjoys it, or has time, etc, but I hope that the reason is
something like time rather than being worried about how to do it correctly.

I'm interested in whether folks who haven't mentored anybody - or who
haven't in a good few years - have any insight on maybe guidance
recruiters could be offering (or people who have mentored extensively)
to make it less intimidating?

(CC'd recruiters@ in case they have any insight on why it tends to only
be a few of us doing that.)

Anyway, I really do believe the way forward is to keep prioritising mentoring
and bringing in new talent. For a while, I believed that people would make
themselves obvious (as in, get to the point where you think "why aren't
they a developer yet?"), but actually, that misses out a load of people!

Approaching folks who seem to do a good job but need some help
has been fruitful. I'd assumed before that maybe they wouldn't be
interested (if they hadn't approached _us_, then maybe it just wasn't
on their radar, and they're happy to proxy maintain bits), but actually,
everybody I've approached has been up for starting the process.

We need more folks coming in who can then in turn process more
contributions and ultimately recruit more.

> - how do we make it easier to do QA on significantly more contributions?

I think gitlab will be a good step forward here for its ease of wiring up
CI runners.

mgorny made reference to possibly running our current CI on every push
which would be a nice win too.

I think a lot of it is tied into the next question, i.e. it's easier to do QA on them
if we know we have good documentation for them and can point them to
resources instead of explaining the same thing informally over and over -
which doesn't scale.

> - what blockers do you perceive in the contribution processes, and how
>  do you think they should be tackled?

- GCO sign off continues to be a bit of an issue for some, but less than it used to be.
I'd continue to advocate for some leniency on the part of the merger if
they deem the changes non-copyrightable. Ultimately, would like to see
some of the GLEP suggestions proposed on -project a while ago possibly revived,
but would need to read through it all again to see where we landed.

Don't intend to rehash the whole thing right now though in this email as
I don't think it's the #1 factor at all.

- Better documentation for our workflow and tooling.

I think we're getting there. Standardising on pkgcheck is helpful here,
because we don't have to include two workflows on every wiki page
and so on.

I've had some feedback that we need some better use case-based
documentation - i.e. "If you want to do X, this is the right way".

I've spent a lot of time on improving the devmanual for bits like this and
plan on continuing with that, although I think the wiki is probably where
most of the confusing resources I hear about are.

- Lack of mergers!

People do tend to get frustrated with time taken to merge PRs. We do
alright or pretty well most of the time (depending on circumstances)
but only a handful of us merge PRs at all en-masse.

We need more people to be comfortable merging PRs - CI
to verify patches apply, a simple default USE flags build works
would go a long way here.

As for patches via Bugzilla, we don't get much of those, and it's
hard for me to have visibility into how many of them get merged.

The occasional mailing list patch to the proxy paint ML goes okay.

Both of those are really insignificant in terms of numbers compared
to PRs though, which is why I focused on it.

> 
> Many of the developers I nominated in my previous email to the -project
> list were because are the very prolific contributors or have significant
> impact in their contributors: how can we increase not just the prolific
> contributors, but get many more contributors everywhere?
> 

I think I've accidentally answered this above, but generally
feel quite strongly about reducing territoriality, which we can
do by making people feel "safe" and knowing their packages
will be taken care of.

For my part, I'm trying to document any gotchas or tricky parts
in any of my packages (both directly and indirectly in projects
I'm a member of).

Do aspire to possibly having a set of notes on the wiki or in metadata.xml
(proposed it before on gentoo-dev, may revive) which would help
a fair bit with this.

The gist being I think we need to make it less scary to step into
an area you don't know.

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]



> On 18 Jun 2022, at 00:14, Sam James <sam@gentoo.org> wrote:
> 
> 
> 
>> On 16 Jun 2022, at 19:06, Robin H. Johnson <robbat2@gentoo.org> wrote:
>> 
>> A question I'd like the candidates to answer.
>> 
> 
> I think mgorny's point about the questions is spot on -- they're not bad ones at all,
> but they need the whole community to engage on them (so I hope non-nominees
> might engage too). Council can't dictate things, and a lot of these aren't
> within its gift, but it is of course important to know what we feel is important.
> 
> All that to say, I hope it prompts a discussion from all corners of the community,
> not just candidates.
> 
>> What do you feel that Council can do to increase the contributions to
>> Gentoo?
>> 

See above.

I'm sorry, I meant to come back to these two questions.


>> - how do you feel technical debt of Gentoo should be measured?

I'm not sure how to measure development velocity other than
number of contributors, number of commits (excluding stable/keywording
gives some useful insight but those are valuable contributions in themselves,
but does help to show how many contributions we get fixing bugs in packages),
and number of open PRs is generally a good sign of health of the proxy-maint project.

[snip]

>> - how do you feel technical debt of Gentoo should be measured?


I'm not completely sure how to answer this bit but I do think making it a habit
to check over Bugzilla for bugs owned by a project is worth doing regularly.

I keep finding things which are either easily solved from years ago -
or already fixed. You can't know what needs doing if there's noise.

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[Michał Górny]

On Sat, 2022-06-18 at 00:14 +0100, Sam James wrote:
> People do tend to get frustrated with time taken to merge PRs. We do
> alright or pretty well most of the time (depending on circumstances)
> but only a handful of us merge PRs at all en-masse.
> 
> We need more people to be comfortable merging PRs - CI
> to verify patches apply, a simple default USE flags build works
> would go a long way here.

This also means we need more developers putting Gentoo ahead of their
personal prejudices and accepting PRs on GitHub.  It's not nice at all
if users submit something just to have it rejected because someone
prefers another workflow.

-- 
Best regards,
Michał Górny

Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[Michael Jones]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On Sat, Jun 18, 2022 at 12:55 AM Michał Górny <mgorny@gentoo.org> wrote:

> On Sat, 2022-06-18 at 00:14 +0100, Sam James wrote:
> > People do tend to get frustrated with time taken to merge PRs. We do
> > alright or pretty well most of the time (depending on circumstances)
> > but only a handful of us merge PRs at all en-masse.
> >
> > We need more people to be comfortable merging PRs - CI
> > to verify patches apply, a simple default USE flags build works
> > would go a long way here.
>
> This also means we need more developers putting Gentoo ahead of their
> personal prejudices and accepting PRs on GitHub.  It's not nice at all
> if users submit something just to have it rejected because someone
> prefers another workflow.
>
> --
> Best regards,
> Michał Górny
>
>
>

Re-evaluating your "signed off by" requirements on github, when that's
legally meaningless, and already covered by the existing github terms of
use, would also go a long way.

I explicitly will not contribute to a project that has that requirement.

https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#d-user-generated-content

[-- Attachment #2: Type: text/html, Size: 1740 bytes --]

Re: [gentoo-project] Taking the signoff bait (was: Gentoo Council 2022-23: Questions for Candidates: how to increase contributions)

[Anna Vyalkova]

On 2022-06-18 19:35, Michael Jones wrote:
> On Sat, Jun 18, 2022 at 12:55 AM Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Sat, 2022-06-18 at 00:14 +0100, Sam James wrote:
> > > People do tend to get frustrated with time taken to merge PRs. We do
> > > alright or pretty well most of the time (depending on circumstances)
> > > but only a handful of us merge PRs at all en-masse.
> > >
> > > We need more people to be comfortable merging PRs - CI
> > > to verify patches apply, a simple default USE flags build works
> > > would go a long way here.
> >
> > This also means we need more developers putting Gentoo ahead of their
> > personal prejudices and accepting PRs on GitHub.  It's not nice at all
> > if users submit something just to have it rejected because someone
> > prefers another workflow.
> >
> > --
> > Best regards,
> > Michał Górny
> >
> >
> >
> 
> Re-evaluating your "signed off by" requirements on github, when that's
> legally meaningless, and already covered by the existing github terms of
> use, would also go a long way.
> 
> I explicitly will not contribute to a project that has that requirement.
> 
> https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#d-user-generated-content

1) We can't see if a commit comes from GitHub or somewhere else in the
git history. This not only makes verification but also breaks
verification tools (commit without signoff are rejected by gitolite's
pre-push hook, github is just a mirror).

2) Gentoo has plans to move to their own GitLab instance. So binding
themselves to GitHub ToS (that can be changes at any time and controlled
by Miscro$oft) is stupid.

3) Commit author != GitHub user.

4) **Most important point!** These ToS apply only to content hosted on
GitHub! And you retain ownership only on github PRs, not the canonical
repo.

* the only thing I dislike and sabotage in Gentoo's signoff policy is
  that uses "legal name" instead of "real name" - change that already...

Re: [gentoo-project] Taking the signoff bait

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]

>>>>> On Sun, 19 Jun 2022, Anna Vyalkova wrote:

> On 2022-06-18 19:35, Michael Jones wrote:
>> Re-evaluating your "signed off by" requirements on github, when
>> that's legally meaningless, and already covered by the existing
>> github terms of use, would also go a long way.
>> 
>> I explicitly will not contribute to a project that has that
>> requirement.
>> 
>> https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#d-user-generated-content

Maybe I am missing something, but where do the GitHub ToS say that we
can take a contribution from a GitHub PR and distribute it outside?

> 1) We can't see if a commit comes from GitHub or somewhere else in the
> git history. This not only makes verification but also breaks
> verification tools (commit without signoff are rejected by gitolite's
> pre-push hook, github is just a mirror).

> 2) Gentoo has plans to move to their own GitLab instance. So binding
> themselves to GitHub ToS (that can be changes at any time and controlled
> by Miscro$oft) is stupid.

> 3) Commit author != GitHub user.

I think it's even three entities: author, committer, and GitHub user,
which can all be different.

> 4) **Most important point!** These ToS apply only to content hosted on
> GitHub! And you retain ownership only on github PRs, not the canonical
> repo.

> * the only thing I dislike and sabotage in Gentoo's signoff policy is
>   that uses "legal name" instead of "real name" - change that already...

That wording went through several iterations, the last of which changed
it from "real name" to "legal name" [1].

IIRC, the rationale behind this change was that "real name" was deemed
to vague, and to account for officially registered pseudonyms.
For example, the German passport has an optional field "religious name
or pseudonym" [2].

Ulrich

[1] https://gitweb.gentoo.org/data/glep.git/commit/glep-0076.rst?id=dcc841a715dfa077258fa3f8bef5f15ee22148cb
[2] https://en.wikipedia.org/wiki/German_passport#Following_page

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-project] Taking the signoff bait

[Anna Vyalkova]

On 2022-06-19 12:33, Ulrich Mueller wrote:
> > * the only thing I dislike and sabotage in Gentoo's signoff policy is
> >   that uses "legal name" instead of "real name" - change that already...
> 
> That wording went through several iterations, the last of which changed
> it from "real name" to "legal name" [1].
> 
> IIRC, the rationale behind this change was that "real name" was deemed
> to vague, and to account for officially registered pseudonyms.
> For example, the German passport has an optional field "religious name
> or pseudonym" [2].
> 
> Ulrich
> 
> [1] https://gitweb.gentoo.org/data/glep.git/commit/glep-0076.rst?id=dcc841a715dfa077258fa3f8bef5f15ee22148cb
> [2] https://en.wikipedia.org/wiki/German_passport#Following_page

You can explain "real name" differently. I'd write:
> like how you introduce yourself to colleagues

I'll send a patch for the GLEP after the elections.

Re: [gentoo-project] Taking the signoff bait

[Michael Jones]

[-- Attachment #1: Type: text/plain, Size: 11489 bytes --]

I'm sorry that you felt like I was trying to troll-bait. It wasn't an
attempt to do so.

I've refused to change a pull request to include "signed-off by" for
multiple projects, including for Gentoo, in the past and had even trivial
1-liners rejected, so it's a real blocker for at least one person to
contribute more to the project. Whether I'm alone in this is unknown to me.

"signed-off by" in plain english simply means "Approved by" in the vast
majority of non-subject-matter-expert's interpretation of it. Further,
different projects *do* use it in that meaning (not in the license
attestation meaning), and other projects use it to mean "I assert that I
hold the right to submit this under this license".  I've also seen, in
multiple different projects, such as OpenWRT, people "helpfully" add the
"signed-off by" line to commits on behalf of people without permission from
the submitter or author.

I would have much less objection if Gentoo used a combination "authored by"
and "license attestation from" or something like that, so that it was clear
in the line itself what the legal ramifications are. Simply saying "for
Gentoo, it means X" is not sufficient to prevent mistakes unless you're
going to plaster it everywhere and require acknowledgement clicks. The room
for misunderstanding the meaning is very high due to the use of a 3-word
term to mean something quite legally complicated when it has a trivial
native-English meaning with no relationship to the legal meaning that the
project (Gentoo) chooses to use it for.

Further considering that they are merely text-lines in a commit statement,
it's rather silly that "signed-off by" is used by Gentoo to have *more*
meaning than the built-in git-commit fields for author name and email.
Though, in fairness, a lot of projects abuse this concept, instead of
adding these custom fields to Git directly.

On Sun, Jun 19, 2022 at 5:33 AM Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Sun, 19 Jun 2022, Anna Vyalkova wrote:
>
> > On 2022-06-18 19:35, Michael Jones wrote:
> >> Re-evaluating your "signed off by" requirements on github, when
> >> that's legally meaningless, and already covered by the existing
> >> github terms of use, would also go a long way.
> >>
> >> I explicitly will not contribute to a project that has that
> >> requirement.
> >>
> >>
> https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#d-user-generated-content
>
> Maybe I am missing something, but where do the GitHub ToS say that we
> can take a contribution from a GitHub PR and distribute it outside?
>
>
From the linked terms of use page.
3. Ownership of Content, Right to Post, and License Grants

You retain ownership of and responsibility for Your Content. If you're
posting anything you did not create yourself or do not own the rights to,
you agree that you are responsible for any Content you post; that you will
only submit Content that you have the right to post; and that you will
fully comply with any third party licenses relating to Content you post.

Because you retain ownership of and responsibility for Your Content, we
need you to grant us — and other GitHub Users — certain legal permissions,
listed in Sections D.4 — D.7. These license grants apply to Your Content.
If you upload Content that already comes with a license granting GitHub the
permissions we need to run our Service, no additional license is required.
You understand that you will not receive any payment for any of the rights
granted in Sections D.4 — D.7. The licenses you grant to us will end when
you remove Your Content from our servers, unless other Users have forked it.
No one may post a pull request to a project hosted on github that they do
not hold the right to post, whether they are the author, or merely posting
on behalf of another.

6. Contributions Under Repository License

Whenever you add Content to a repository containing notice of a license,
you license that Content under the same terms, and you agree that you have
the right to license that Content under those terms. If you have a separate
agreement to license that Content under different terms, such as a
contributor license agreement, that agreement will supersede.

Isn't this just how it works already? Yep. This is widely accepted as the
norm in the open-source community; it's commonly referred to by the
shorthand "inbound=outbound". We're just making it explicit.

Contributions made to a repository that have an explicitly configured
license in the github project's settings are licensed under the terms of
that project's license, unless otherwise explicitly stated or agreed to via
some other mechanism (e.g. the commit message or contents of the commit
have wording to indicate an alternative license). It's the project's
responsibility to ensure that pull requests / commits that have wording to
indicate an explicit license are not merged unless the explicitly specified
license is acceptable. If no explicit license wording is present, then the
Github project's configured license (e.g. whatever Gentoo set on github) is
explicitly the license for the contribution.

As such, there is no need to use "signed-off by" for contributions made on
github, as the same legal infrastructure for assuring that commits are
legally/rightfully contributed by random internet strangers that Github has
also applies to the Gentoo project (mirror or otherwise) on Github.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

From this point, it appears you're responding to someone else, but I'll
attempt to answer.

> 1) We can't see if a commit comes from GitHub or somewhere else in the
> > git history. This not only makes verification but also breaks
> > verification tools (commit without signoff are rejected by gitolite's
> > pre-push hook, github is just a mirror).
>

That's something that could be solved by tooling, either by changing the
license that's configured on github to say that any PRs will be modified to
include the "signed-off by" line, or by using Merge commits from the PR ->
the official git repository done by an automated system that contains
wording like "This was a contribution made under the github.com terms of
use, blahblahblah".

Many (most?) drive-by contributors won't have any interest in contributing
to Gentoo via gitolite. If you don't plan to accept PRs on github in the
future, then this discussion is rather irrelevant, and I'm sorry for
stirring the pot.

But since we are discussing in the original thread how to improve external
contributions, I advise adjusting your tooling to be more welcoming, rather
than insisting external contributors accept your tooling's limitations.


> > 2) Gentoo has plans to move to their own GitLab instance. So binding
> > themselves to GitHub ToS (that can be changes at any time and controlled
> > by Miscro$oft) is stupid.
>

I don't think this is very helpful to the stated intention of improving the
situation with external contributions. Moving to GitLab doesn't do anything
useful from the perspective of external contributors. I have a github
account. I won't be making one on the Gentoo GitLab, unless it's.... via
logging into Github, which many GitLab instances allow.

The Github terms of use are basically harmless to Gentoo, and they provide
Gentoo with plenty of legal backing in terms of attesting that a
contribution was done legitimately. Which asking for random internet people
to add "signed-off by" does *not* provide. When I was asked to add
"signed-off by" for multiple projects, including Gentoo, no explanation of
the legal meaning behind that was given. I *assumed* they were asking me to
attest that the PR wouldn't introduce any QA problems, which is the plain
meaning of "signed-off by" in English to non-legal experts. Rather the
opposite of what Gentoo wants to use it for.

However, the Github terms of use are quite clear and easy to understand. No
one can be confused by what the expectations are for contributions made on
Github, and you'd be able to point any legal trouble at the Github legal
team for violations of the Github TOS. Since Github's entire business model
requires that their terms of use apply properly, they would have a heavy
incentive to defend Gentoo on that issue if the commit came from a Github
PR.

Further, Microsoft hosts and accepts PRs for some of its own commercial
products like Visual Studio's standard library for C++, without a CLA as
far as I know. How is this legally fine for Microsoft for a product they
commercially sell, but not for Gentoo which does not commercially sell
anything (that I know of, anyway)?



> > 3) Commit author != GitHub user.
>
> I think it's even three entities: author, committer, and GitHub user,
> which can all be different.
>
>
That seems accurate.


> > 4) **Most important point!** These ToS apply only to content hosted on
> > GitHub! And you retain ownership only on github PRs, not the canonical
> > repo.
>

I don't see how this is accurate. Gentoo doesn't own any of the PRs or
commits or patches submitted to it in the first place. That ownership is
retained by the original author, or whoever they've assigned the ownership
of. Are you telling me that the handful of patches / ebuilds that I've sent
to Bugzilla are somehow no longer owned by me? That's a surprise...

"signed-off by" is not a transfer of ownership, even in the flawed way that
Gentoo is trying to use it.

If you're expecting to see ownership transfer, you need a real contributor
license agreement that explicitly transfers ownership, which I've not seen
anyone ever discussing on the Gentoo mailing list (which could mean I
simply missed the discussion).

Once the commit is made on GitHub, the GitHub TOS assures Gentoo that the
person who submitted the PR had the right to do so under the Github TOS and
the license that the PR was submitted as. Now that the license is
established, Gentoo can do whatever Gentoo want's to with that PR, so long
as the license it was submitted under allows it. No need for "signed-off
by" or ownership transfer, unless you're planning to re-license things?



> > * the only thing I dislike and sabotage in Gentoo's signoff policy is
> >   that uses "legal name" instead of "real name" - change that already...
>
> That wording went through several iterations, the last of which changed
> it from "real name" to "legal name" [1].
>
> IIRC, the rationale behind this change was that "real name" was deemed
> to vague, and to account for officially registered pseudonyms.
> For example, the German passport has an optional field "religious name
> or pseudonym" [2].
>
> Ulrich
>
> [1]
> https://gitweb.gentoo.org/data/glep.git/commit/glep-0076.rst?id=dcc841a715dfa077258fa3f8bef5f15ee22148cb
> [2] https://en.wikipedia.org/wiki/German_passport#Following_page


I find it really weird that I was able to make an account on Github, and
submit code through them, without needing to provide my real *or* legal
name.

What makes Gentoo special that it needs this additional information, when
Github (and thus Microsoft) does not, even for Microsoft's own commercial
products hosted on Github?

[-- Attachment #2: Type: text/html, Size: 14506 bytes --]

Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[Georgy Yakovlev]

On Thu, 2022-06-16 at 18:06 +0000, Robin H. Johnson wrote:
> A question I'd like the candidates to answer.
> 
> What do you feel that Council can do to increase the contributions to
> Gentoo?
> 
> - how do you feel development velocity of Gentoo should be measured?

I'll measure the following:
 - commit amount and frequency, if a person contributes already.
 - responsiveness on bugs.gentoo.org
 - community interaction: irc, bugtracker, ml, github, media (forums,
reddit, etc)

TLDR: if a person ignores bug-reports, bump-requests and general
feedback, I would not consider those as a valuable contributor.
Either retire, set devaway, or do the work.

> - how do you feel technical debt of Gentoo should be measured?
Not sure if it's possible to measure at this point.
One has to be a pretty active member of developer community to actually
see important things happening here and there. Maybe if we could
introducde a special bug tag/category it'd have more visibility.

> - how do we make it easier to get orders of magnitude more
> contributors?

We can increase number of contributions by paying more attention to
github PRs, active GURU members and bugs with PATCHes.
Not something council can directly influence, but it's something
council can encourage.

> - how do we make it easier to do QA on significantly more
> contributions?

I don't want to associate this particular member of developer community
with the QA team, but some QA-related bug reports could use fine-tuning
in a way those are reported.
Internal politics is invisible to external contributors, but pretty
much anyone can get this kind of QA report, even GURU contributors, and
random publically accessible repos/overlays.

For example, filing a bug as gentoo-ci would reduce perceived pressure
and encourage more bug handling.
I've reported this couple of years ago (see what I did here?) with no
reaction:
https://github.com/asarubbo/ci/issues/1

Releasing source code could also encourage more contributions and
improvement of the ego-CI.
I'd certainly would like to fine-tune some reports and maybe even
disable some.
https://github.com/asarubbo/ci/issues/2

> - what blockers do you perceive in the contribution processes, and
> how
>   do you think they should be tackled?

Inability of some members of dealing with github(tm) PRs is a major
factor, unfortunately.

Genrally council could encourage review of external contributions,
maybe even organise a PR-bugday, dedicated to reviewing and merging
github PRs.

> 
> Many of the developers I nominated in my previous email to the
> -project
> list were because are the very prolific contributors or have
> significant
> impact in their contributors: how can we increase not just the
> prolific
> contributors, but get many more contributors everywhere?

Council nominations, while is certainly is a popularity contest, also
reflects community preception of candidate's abiility to voice and
defend opinions.
Finding leadership is always hard, but if we could encourage developers
to share their opinions with community and not be afraid of judgement -
we'd get more contributions and probably more council candidates.

Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[John Helmert III]

[-- Attachment #1: Type: text/plain, Size: 3273 bytes --]

I'm sorry for the belatedness in my response, I've been away for much
of the voting period.

I agree with some of the other's sentiment that these aren't entirely
useful questions for council given council only acts on what is
brought to it, but further replies below.

On Thu, Jun 16, 2022 at 06:06:40PM +0000, Robin H. Johnson wrote:
> A question I'd like the candidates to answer.
> 
> What do you feel that Council can do to increase the contributions to
> Gentoo?
> 
> - how do you feel development velocity of Gentoo should be measured?
> - how do you feel technical debt of Gentoo should be measured?

I think Repology provides some useful metrics related to these
questions:

https://repology.org/repository/gentoo

Somewhat less quantitatively, technical debt should also take into
account this like bugs with PATCHes that haven't been handled by the
maintainer(s), pull requests that remain ignored/unreviewed by
maintainer(s), and how well sets of bugs on Bugzilla (i.e. bugs
assigned to a maintainer or bugs for a specific package) are
maintained. It's always a bit frustrating to find a package with
several years of bugs that haven't been touched by the assignee.

> - how do we make it easier to get orders of magnitude more contributors?
> - how do we make it easier to do QA on significantly more contributions?
> - what blockers do you perceive in the contribution processes, and how
>   do you think they should be tackled?

I'll echo tooling as one of the big barriers in contribution. In the
last year or two we've made leaps forward here, maybe most notably
with pkgdev and iwdevtools. Slyfox also mentioned some tooling he'd
like to see in his retirement blog post:

https://trofi.github.io/posts/226-farewell-gentoo-dev.html

A better CI process for user contributions would allow us to process
user contributions much faster. This is one of the primary goals I see
in transitioning to Gitlab. The current process of users opening a PR
and needing someone to manually build-test it and report back any
issues is tedious and slow, and we'd do better with some automated CI
here.

> 
> Many of the developers I nominated in my previous email to the -project
> list were because are the very prolific contributors or have significant
> impact in their contributors: how can we increase not just the prolific
> contributors, but get many more contributors everywhere?

We have many, many contributors who are already proxied-maintainers
and we could probably do a better job of encouraging these maintainers
to become developers. If we had a build CI process that automatedly
reported issues with contributions, the human dependency for this
would be largely eliminated and contributors wouldn't have to wait for
a human to test their changes and report issues. I think this would
greatly decrease the time the average PR spends open, most of which is
waiting for human action. With a faster turnover for PRs, more PRs can
be made more quickly.

> 
> -- 
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
> E-Mail   : robbat2@gentoo.org
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

Hi all,

I've also been pretty busy this voting period, so sorry about that, but
I will attempt to answer these questions as well.


> On Thu, Jun 16, 2022 at 06:06:40PM +0000, Robin H. Johnson wrote:
> > A question I'd like the candidates to answer.
> > 
> > What do you feel that Council can do to increase the contributions to
> > Gentoo?

This one is difficult because the council really doesn't control
contributions. I do think that we are heading into a good place for
this however. With the addition of gitlab, I think we can possibly make
it easier for folks to contribute.

Also, while the proxy maintainers project is a good thing, I would like
to see a push for proxy maintainers to become developers.

> > - how do we make it easier to get orders of magnitude more contributors?
> > - how do we make it easier to do QA on significantly more contributions?
> > - what blockers do you perceive in the contribution processes, and how
> >   do you think they should be tackled?

I agree with the sentaments about tooling already mentioned. Better
tooling would make things much easier.

This also includes keeping the stable tree relevant. I know for me, and
probably for a lot of maintainers, stabilization is a lot of work. I
think there needs to be a way (with opt out by maintainers of course)
that packages can be stabled automatically after 30 days in the tree.

> > Many of the developers I nominated in my previous email to the -project
> > list were because are the very prolific contributors or have significant
> > impact in their contributors: how can we increase not just the prolific
> > contributors, but get many more contributors everywhere?

Like I said above, I think one thing we should do is actively encourage
proxy maintainers to become developers.

I am hoping that the transition to gitlab will include moving all of our
work over there and not accepting prs from github. That way everyone
will contribute through the same workflow.

Thanks,

William

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[Michał Górny]

On Fri, 2022-07-01 at 18:07 -0500, William Hubbs wrote:
> I am hoping that the transition to gitlab will include moving all of
> our
> work over there and not accepting prs from github. That way everyone
> will contribute through the same workflow.

I would really prefer if someone worked on the GitLab accessibility
issues before someone tried to do that.  Like, made GitLab something
more than a blank site on less-than-state-of-art web browsers.

-- 
Best regards,
Michał Górny

Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[Anna V.]

On 2022-07-02 04:58, Michał Górny wrote:
> On Fri, 2022-07-01 at 18:07 -0500, William Hubbs wrote:
> > I am hoping that the transition to gitlab will include moving all of
> > our
> > work over there and not accepting prs from github. That way everyone
> > will contribute through the same workflow.
> 
> I would really prefer if someone worked on the GitLab accessibility
> issues before someone tried to do that.  Like, made GitLab something
> more than a blank site on less-than-state-of-art web browsers.

SourceHut is the only sort-of-accessible FOSS forge. Both GitLab and
Gitea have issues with accessibility (screen readers support, keyboard
navigation, browser support etc). However people are used to
GitHub-style workflow more.

GitHub is accessible (except for browser support) but not FOSS.

Re: [gentoo-project] Gentoo Council 2022-23: Questions for Candidates: how to increase contributions

[Alec Warner]

On Fri, Jul 1, 2022 at 8:48 PM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Fri, 2022-07-01 at 18:07 -0500, William Hubbs wrote:
> > I am hoping that the transition to gitlab will include moving all of
> > our
> > work over there and not accepting prs from github. That way everyone
> > will contribute through the same workflow.
>
> I would really prefer if someone worked on the GitLab accessibility
> issues before someone tried to do that.  Like, made GitLab something
> more than a blank site on less-than-state-of-art web browsers.

I'm tracking requests for gitlab, so far the only 2 outstanding things
I am aware of are:
 - Add additional login possibilities (so e.g. external contributors
can use our gitlab.)
 - sync groups from some internal gentoo sources, so we can help
people configure groups and repos on gitlab.

If there are other concerns, please bring them to my attention in
#gentoo-gitlab or email gitlab@gentoo.org or file a bug against infra
in the git component.

Thanks,
-A

>
> --
> Best regards,
> Michał Górny
>
>