unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
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


  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

  List information: https://guix.gnu.org/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).