3 ms·
> The "importance" of the mailing list I'm trying to emphasize is the Schelling Point. You have said Schelling Point enough times for me to have caught that. I
by arghwhat 6y ago
> The "importance" of the mailing list I'm trying to emphasize is the Schelling Point.
You have said Schelling Point enough times for me to have caught that. It is, however, not correct to assign this to the mailing list.
(Also, as a side-note, "focal point" is a more natural, common, and much less awkard term.)
> The list also acts as a Schelling Point to coordinate and consolidate public discussions.
No, it does not. However, it does serve a similar (albeit unimportant) function: providing visibility into ongoing discussions for outsiders, as well as a way for people to join a discussion there were not otherwise introduced into by fellow maintainers.
As a point of reference, during the handful of kernel patches I have gotten upstreamed, the mailing lists themselves served no function. My only interaction with them was to Cc them, as per the guidelines. I did not read them, and all my interaction was with the individuals I To: or Cc:'d directly.
A key thing to note here is that historical discussions on a mailing list are not particularly important in mailing-list style development, as all relevant information should be in the commit message that the discussion culminated in. Likewise, being able to chime in on ongoing discussions are, on its own, not truly that important either—in the worst case, something bad is implemented, and someone upon discovering this starts a new discussion and possibly end up changing it.
In big, or long-standing projects, this happens relatively often, as no individual has the bandwidth (or interest) to keep up with every discussion, and relies mostly on being introduced to discussions when others find them relevant (with git history revealing if they are relevant).
> A mailing list also has a Schelling Point aspect where people can discover email addresses of maintainers.
> How would new people easily discover the maintainers' email addresses without any Schelling Points?
> I disagree. Today, if I notice a bug where youtube-dl is broken, I don't have a canonical place to report the issue.
These are all the same argument, which I will consolidate as: "You cannot discover the target address if the mailing list is down".
This is entirely false: the mailing list does not serve the function of email address discoverability in any form. Instead, the source is the source code itself, in which the target email addresses will be recorded ad nauseam.
Not only will you as holder of the source have the email address of every historic contributor and maintainer (including knowledge of who is relevant to what area), there will usually also be explicit listings available (README, maintainer lists, etc.). External sources might redundantly cover the information as well, but that is non-critical.
To carve it out: You, as a holder of the source code, will always be able to send patches, ask questions, as well as start discussions that others will organically be added to, using no other sources of information than the source, irrespective of mailing list availability, as long as you can send email, and that at least one of the maintainers or contributors of the source can still receive email.
- jasode 6y ago>the mailing list does not serve the function of email address discoverability in any form. Instead, the source is the source code itself, in which the target email addresses will be recorded ad nauseam. Not every project records email addresses in the source code. Yes, the project maintainers could do that, but some don't. I'm looking inside the latest "youtube-dl-2020.11.01.1.tar.gz" source archive and it does not have maintainers' email addresses in it. The main Python source code file "YoutubeDL.py" and other .py files do not have email addresses. The archive also has a text file "AUTHORS" for historical credits -- but no actual email addresses. I suppose the current maintainer could explicitly put his email address in that source, but he/she didn't. (Maybe there are good reasons to avoid putting an email address in the source code.) >To carve it out: You, as a holder of the source code, will always be able to send patches, ask questions, as well as start discussions that others will organically be added to, using no other sources of information than the source, irrespective of mailing list availability, as long as you can send email, and that at least one of the maintainers or contributors of the source can still receive email. Based on what you wrote, it seems you still have not fully internalized the difficulties of a Schelling Point for something like Youtube-dl. Even if "youtube-dl-2020.11.01.1.tar.gz" contained the actual email address of the current maintainer, if that maintainer decides to quit because of RIAA hassles and someone else (unknown to us because we can't predict identities of future authors) takes over and creates a new "youtube-dl-2021.03.15.1.tar.gz", the old "tar.gz" file does not point to the existence of the new file or new canonical location. The world still needs a Schelling Point so people know where to download the latest trusted non-malware version of Youtube-dl even if they don't know the identity of the new maintainer. You claim the "source" can be the starting point ex nihilo but you still need a trusted Schelling Point to obtain the source in the first place to enable the subsequent steps of private email correspondence that make a mailing list server irrelevant. How do people get the latest "youtube-dl-202x.xx.xx.x.tar.gz" without a Schelling Point?!? Your answer: start with the source code. My response: isn't that circular logic? I can only guess that you're using mental model of Linux kernel development. The problem with trying to transfer that collaboration workflow over to youtube-dl is the Linux project does not have adversaries like RIAA trying to kill it. Schelling Points are stable in that world of mainstream projects and seemingly trivial. E.g. just read the Linux kernel .h/.c file for email addresses.