Indexes: add People index

[kouloumos]

Overview

Topics' mentions are currently manually updated with every newsletter. But the current writing flow and structure of the newsletter allows for automated calculation of mentions.
This PR introduces two main features:

• Automated optech mentions from newsletters
• A new People index that leverages and enhances automated mentions

Topics automated mentions

The goal is to automate topics' mentions without degrading the experience. The 1st commit introduces the bidirectional linking logic by adding support for double-bracket link syntax [[]]. When [[]] is used, the parser in bidirectional_links_generator.rb creates a new mention from the newsletter to the [[topic]], using the title of the paragraph as the title of the mention.

The 2nd commit showcases this new logic by making a few changes to a recent newsletter in order for automated mentions to start working. Automated mentions are backwards-compatible with the manual mentions.

Limitations

When optech_mentions are manually added they often include a more descriptive title than just the title of the paragraph.
For example, news item LDK #1794 from newsletter #251:

bitcoinops.github.io/_posts/en/newsletters/2023-05-17-newsletter.md

Lines 206 to 208 in a051a45

	- [LDK #1794][] begins adding support for [dual funding][topic dual
	funding], starting with methods needed for the interactive funding
	protocol that is used for dual funding.

when it was mentioned in the dual funding topic it was added as

bitcoinops.github.io/_topics/en/dual-funding.md

Lines 110 to 111 in a051a45

	- title: "LDK #1794 begins adding support for dual funding"
	url: /en/newsletters/2023/05/17/#ldk-1794

but with the new automated mentions logic it will be displayed as just LDK #1794 because the rest of the text cannot be derived from the writing style. You can see this in action in the newsletter podcast recaps (example) as the newsletter-reference logic introduced with #1083 shares some of the same implementation details.

Dealing with Limitations

If this limitation is a deal-breaker, we could introduce some minor changes in the writing style of the newsletter that would allow for the parser to detect a more descriptive title to add to the mention. The exact solution is still an open question.

New index for People

The 3rd commit adds a page /en/people that provides another way to navigate the website and gather context based on what people are working on. Because it makes use of the automated mentions logic it doesn't need any manual work except of using the new linking syntax as shown in the 4th commit.

The automated mentions logic can allow for more verbose mentions and easier creation of them.
That's how I originally started working on this; I imagined an enhancement of the topics page mentions that would allow for more efficient context gathering, kind of like I did in bitcoin-core-review-club/website#639. That original idea is not part of this PR as I later realized that it would be a breaking change for a non-validated idea.

The 5th commit is that same enhancement but instead applied on the newly introduced people index:

The above screenshot also includes the podcast mentions functionality that is introduced with the 6th commit and showcased with the 7th commit.

This PR contains only a limited number of People as a way to showcase the feature. If there is positive sentiment for this feature, I could add the rest of the people in a subsequent PR(s).

Build time change: I see a 6s increase in my local builds, from ~66s to ~72s.

Open Questions

• Is automated mentions for Topics a feature worth having?
  • If yes, what do you think about the described limitation?
  • Would it make sense for Topics mentions to be also verbose?

[harding]

@kouloumos another amazing feature! Some quick thoughts:

1. We've discussed before changing how we do the bullet title in the Notable Changes section before. (The previous motivation was that we thought maybe some readers missed a Bitcoin Core merge that added a full-rbf configuration flag, so we thought emphasizing the key change rather than the project name + PR number would help, at least a bit.) So I think that combines well with this.

2. I've privately discussed with @bitschmidty updating and expanding our topic pages and then using them in printable material (like a short book). Given that they're currently YAML with some Markdown fields, it's easy for me to write a script to dump that out into something that can be used by any text-to-(ePUB|PDF) compiler. However, if some of their content is automatically pulled from other parts of the site, the scripting I'd need to do would be a lot more complicated.

   I don't think that's necessarily incompatible here. Maybe bidirectional_links_generator.rb could (1) check the optech_mentions array before adding a link to see if there's already an entry with exactly the same URL (including the # local anchor); if so, don't add anything; and (2) when adding an automatic entry, output a debug warning that would make it easy for us to manually add an entry to the topic page later (e.g., output it in the same YAML formatting we currently use to define entries). Then I could go back and add topic entries in bulk potentially months after we'd published the newsletters using the automatic links. Ideally, that debugging output would only be displayed if we ran jekyll with a special flag, or it'd be written to a debug.log, or something else that would be out of the way during normal use.

3. I have mixed feelings about the people index. I really like collecting all of that information, but I'm worried that it's unfair related to the way we attribute things in the newsletter. (Which is a more fundamental issue on our side, I admit.) The problem is that we tend to use names a lot in the News section because we're often reporting on mailing list posts made by individuals or small groups which are expressing their ideas and opinions. By contrast, in the Notable Changes section, we have a rule to (almost) never use names because a merge represents the direction of an entire project and because it's impractical for us to determine for every PR who made the most significant contributions to it (because reviewers can contribute as much, if not more, than the author(s)). I don't want People pages that make it look like Wladimir van der Laan and Marco Falke made insignificant contributions to Bitcoin because they almost never post to the mailing list, despite the huge amounts of review and testing they've supported over the years, alongside pages that make other people who post their every complaint to the mailing list (but contribute almost no code or meaningful review at all) look like major contributors.

   That said, I love the idea of using People pages for guests on the podcasts. I would also love to see an index for every project we track, e.g. /en/people/bitcoin-core/ listing each time we linked to one of its PRs or issues.

That's my quick take, besides saying again that this looks amazing!. I'll try to find some time to dig in deeper next week.

[bitschmidty]

On the podcast side of things, it would be very easy for me to add the [[]] tagging for participants on our weekly show, since we already list them on each podcast page. I would commit to doing that portion, if the team agreed it would be interesting for the site.

I think a mentions outside of explicit podcast guests could be a bit hairy, resulting in some folks being discouraged due to their type of work not being acknowledged) and others attempting to game the mentions (or am I thinking too highly of Optech that someone would try to game Optech mentions?).

Would it be possible to auto-generate the people/ pages when someone new is referenced?

Dave is both the primary topic author as well as the one that provides the weekly manual entries, so on those items I'd defer to him. Additionally, Dave's idea of compiling topics that is affected potentially here.

Dave's idea of the project index could be interesting as well, not sure if that could be a separate PR or consideration or bundled in here.

@kouloumos thanks for opening this and waiting so long for feedback.