From: indieterminacy <indieterminacy@libre.brussels>
To: Andreas Enge <andreas@enge.fr>
Cc: MSavoritias <email@msavoritias.me>,
Simon Tournier <zimon.toutoune@gmail.com>,
Attila Lendvai <attila@lendvai.name>, Ian Eure <ian@retrospec.tv>,
guix-devel <guix-devel@gnu.org>
Subject: Re: rewriting history; Was: Concerns/questions around Software Heritage Archive
Date: Fri, 22 Mar 2024 22:48:12 +0000 [thread overview]
Message-ID: <079133dac4c502715a033d983b601e27@libre.brussels> (raw)
In-Reply-To: <ZfhaX6D21KOy7CG7@jurong>
On 2024-03-18 15:14, Andreas Enge wrote:
> Am Mon, Mar 18, 2024 at 04:33:49PM +0200 schrieb MSavoritias:
>> Actually gitlab already is facing something like that and they are
>> doing
>> what was proposed elsewhere: mapping of UUIDs to display names
>> https://gitlab.com/gitlab-org/gitlab/-/issues/20960
>
> Interesting, thanks! It is something that maybe could be implemented by
> Savannah, but it would probably require a bit of thought. And yet
> again,
> somehow the mapping uuid<->"real" names would have to be public (people
> would "git clone" commits with uuids, and would need to locally replace
> them by "real" names); so people can always keep copies of the mapping
> over time.
>
> I am also not quite sure about the signing process for committers;
> in principle keys are enough, but in GPG they are tied to email
> addresses,
> and I do not know whether we use this in Guix.
>
> In the end, my impression is this will not achieve much more than what
> we
> already have with the .mailmap approach. In a sense, everyone would use
> a pseudonym (their uuid), and then we would keep a mapping between
> these
> pseudonyms and, well, "real" names or other pseudonyms chosen by the
> contributors...
>
> Hm, this could indeed be implemented exactly with .mailmap, no?
> We would need to enforce that authors use a uuid of a specific format,
> and potentially an empty or dummy email address, or another uuid.
> Then we could keep a .mailmap file. The history of "real" identities
> would still be visible in the git history, but as said above, anyway
> we could not prevent people from storing the association information
> over time.
>
>> Right fair. As I have said before SWH does break Guix CoC effectively
>> right
>> now.
>> So what Guix does from this point on will effectively dictate if the
>> CoC is
>> valid or not.
>
> Well, the CoC is valid on our communication channels; so what SWH does
> with
> our software is outside its scope (that is governed by the license).
>
> Andreas
I have happened to stumble across a new initiative concerning UUIDs for
academic researchers.
Here is their description:
```
ORCID, which stands for Open Researcher and Contributor ID, is a free,
unique, persistent identifier (PID) for individuals to use as they
engage in research, scholarship, and innovation activities. We provide
ORCID to researchers free of charge so that we may realize our vision of
connecting all who participate in research, scholarship, and innovation
are uniquely identified and connected to their contributions across
disciplines, borders, and time.
```
Here are its guiding principles:
```
Our Founding Principles
ORCID will work to support the creation of a permanent, clear, and
unambiguous record of research and scholarly communication by enabling
reliable attribution of authors and contributors.
ORCID will transcend discipline, geographic, national, and
institutional boundaries.
Participation in ORCID is open to any organization that has an
interest in research and scholarly communications.
Access to ORCID services will be based on transparent and
non-discriminatory terms posted on the ORCID website.
Researchers will be able to create, edit, and maintain an ORCID
identifier and record free of charge.
Researchers will control the defined privacy settings of their own
ORCID record data.
All data contributed to ORCID by researchers or claimed by them will
be available in standard formats for free download (subject to the
researchers’ own privacy settings) that are updated once a year and
released under a CC0 waiver.
All software developed by ORCID will be publicly released under an
Open Source Software license approved by the Open Source Initiative. For
the software it adopts, ORCID will prefer Open Source.
ORCID identifiers and record data (subject to privacy settings) will
be made available via a combination of no-charge and for-a-fee APIs and
services. Any fees will be set to ensure the sustainability of ORCID as
a not-for-profit, charitable organization focused on the long-term
persistence of the ORCID system.
ORCID will be governed by representatives from a broad cross-section
of stakeholders, the majority of whom are not-for-profit, and will
strive for maximal transparency by publicly posting summaries of all
Board meetings and annual financial reports.
```
While I do not have the focus to make a further evaluation,
I should point out that ORCID is a component of the nascent Open Science
Network
https://openscience.network/
FWIW, recognising an academic in OSN and being aware of the quality of
the tooling Bonfire Networks make me wonder whether ORCID has some good
design principles
https://bonfirenetworks.org/
In any case, it may provide a practical point for comparison given the
thicket of governance issues this thread has discovered.
Warmest regards,
fsnjfkjlffffjcjcjcdnmddfnfdfnlzxvcllnjnrejvns v fjfdsjhsv
next prev parent reply other threads:[~2024-03-22 22:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 0:10 rewriting history; Was: Concerns/questions around Software Heritage Archive Attila Lendvai
2024-03-18 10:10 ` MSavoritias
2024-03-18 11:26 ` Simon Tournier
2024-03-18 12:08 ` Daniel Littlewood
2024-03-18 21:14 ` Tomas Volf
2024-03-19 10:04 ` Attila Lendvai
2024-03-18 13:35 ` Andreas Enge
2024-03-18 14:03 ` MSavoritias
2024-03-18 14:19 ` Andreas Enge
2024-03-18 14:33 ` MSavoritias
2024-03-18 15:14 ` Andreas Enge
2024-03-18 15:34 ` MSavoritias
2024-03-22 22:48 ` indieterminacy [this message]
2024-03-18 10:51 ` pelzflorian (Florian Pelz)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=079133dac4c502715a033d983b601e27@libre.brussels \
--to=indieterminacy@libre.brussels \
--cc=andreas@enge.fr \
--cc=attila@lendvai.name \
--cc=email@msavoritias.me \
--cc=guix-devel@gnu.org \
--cc=ian@retrospec.tv \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.