Podcasts about MediaWiki

In this podcast episode, host Michelle Frechette welcomes Carrie Dils, Mika Epstein, and Ryan McCue to discuss their roles in the WordPress community and the new FAIR project. The group explores FAIR's mission to create a federated independent repository system for WordPress plugins and themes, focusing on decentralization, community-driven moderation, inclusive governance, and privacy. They address challenges like supporting premium plugins, reducing environmental impact, and fostering global participation. The episode highlights FAIR's collaborative, open-source approach and invites listeners to get involved through GitHub and community meetings, aiming to shape a more innovative and inclusive WordPress ecosystem.Top Takeaways:FAIR Is Reimagining Plugin Discovery and Trust for WordPress: FAIR is building a more open, decentralized ecosystem for WordPress plugin discovery—empowering both end users and developers. By enabling verified directories and authenticated plugin listings (via methods like DNS verification), FAIR provides an alternative to the limitations of the WordPress.org repo, while increasing transparency, user safety, and trust.Community Participation Is Central to FAIR's Success: The FAIR initiative is deeply community-driven. Contributors are encouraged to get involved through GitHub Discussions, introduce themselves, offer help, or join working groups. The leadership team is intentionally building these groups based on people's skills and availability, rather than predefined roles—making FAIR flexible, inclusive, and open to evolving needs.FAIR Encourages Innovation Outside Traditional WordPress Constraints: The project provides an alternative path for plugin creators who may not want to follow the traditional WordPress.org model (e.g., having to release a free version first). With FAIR, creators can request to be listed in aggregator directories that are more flexible, values-aligned, or niche-focused—fostering innovation and lowering barriers to entry.FAIR Is Still in Early Development—and Actively Growing: While the FAIR plugin and protocol are live (accessible via fair.pm), the ecosystem is in its formative stages. The team is prioritizing essential needs (the “MVP”) and building infrastructure to support future growth in documentation, marketing, design, development, and user testing. They welcome feedback on plugin issues, conflicts, and ideas, encouraging broad experimentation and iteration.Mentioned in the Show:FAIRLinkedIn LearningAwesome MotiveLez Watch TVHuman MadeAspire PressGravatarLinux Foundation ProjectBlueskyWPCCBlack PressMastodon DrupalCourtney RobertsonAutomatticMediaWikiMonster InsightsGravity FormsFastly

Welcome to another engaging episode of the Maintainable Software Podcast! In this episode, Robby sits down with Moriel Schottlender, Principal Software Engineer at the Wikimedia Foundation, to explore the complex journey of modernizing MediaWiki, the software behind Wikipedia. Moriel shares her insights on what it takes to keep an enormous monolithic codebase maintainable while supporting an ever-growing and diverse set of global users. She highlights the importance of modularization, ownership, and the delicate balance between flexibility and stability in open-source software.Key Takeaways[00:00:51] Characteristics of Well-Maintained Software: Moriel discusses the three crucial characteristics of well-maintained software: ownership, modularization, and documentation.[00:01:09] Ownership and Rules for Contribution: Ownership goes beyond just fixing bugs—it involves understanding the architectural purpose and maintaining consistency even as teams change.[00:03:35] Product Vision's Role in Maintainability: Why a clear product vision is essential for maintaining software, even in the face of organic growth.[00:07:14] Balancing Experimentation and Long-Term Planning: Moriel shares insights into how Wikimedia balances rapid experimentation with careful, long-term architectural planning.[00:07:32] The Evolution of MediaWiki: MediaWiki's growth from a small project to the backbone of Wikipedia, now supporting over 900 wikis, and the challenges that come with scaling.[00:14:18] Modernizing a 23-Year-Old Monolith: Robby and Moriel dive into the challenges of modernizing MediaWiki's architecture, including the difficulties of updating a monolithic structure.[00:17:15]Wikitext vs. Markdown: Moriel explains why MediaWiki uses its own Wikitext language instead of Markdown and the unique challenges it presents.[00:22:25] Architectural Flexibility for the Future: The importance of having a flexible architecture that can adapt to the evolving needs of users and technologies.[00:26:04] Technical Debt and Modularization: How Wikimedia approaches technical debt in MediaWiki and prioritizes architectural interventions to improve modularity and maintainability.[00:39:00] Community Contributions to MediaWiki: Strategies for increasing developer contributions and how Wikimedia empowers volunteers while maintaining software quality.[00:41:59] Advice for Aspiring Open Source Contributors: Moriel shares encouraging words for anyone looking to contribute to open-source projects, emphasizing that everyone can make a meaningful impact.[00:35:44] The Role of Documentation: Moriel discusses Wikimedia's efforts to improve documentation and ensure it's useful for both developers and end-users, leveraging the strengths of wiki-based contributions.[00:30:29] Celebrating Small Wins: Moriel talks about how Wikimedia celebrates small victories to keep team morale high in the face of big challenges.Resources MentionedMoriel's WebsiteMoriel on MastodonMediaWiki DocumentationBook Recommendation:Year Zero by Rob ReidConnect with MorielMoriel on LinkedInInstagramTwitterGitHubMastodonThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Use the code maintainable to get a 10% discount for your first year. Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Hoy abordamos un problema común en muchos grupos de investigación: la organización de la información. Uno de los problemas más frecuentes es la pérdida de tiempo buscando información. Muchas veces, la información está desorganizada, con documentos y datos dispersos en diferentes lugares. Esto no solo dificulta el acceso a la información, sino que también genera problemas de colaboración entre los miembros del grupo. Además, es común encontrar que los protocolos y documentos clave no se actualizan regularmente, lo que puede llevar a la utilización de información desactualizada o incorrecta. Otro problema es la duplicidad de información, donde diferentes versiones de un mismo documento pueden coexistir, generando confusión. Finalmente, cuando los miembros del grupo se van, se corre el riesgo de perder información valiosa que solo ellos conocían. Estos problemas tienen un impacto significativo en la eficiencia del grupo de investigación. Los nuevos miembros pueden tener dificultades para ponerse al día, y la realización de tareas y experimentos se vuelve ineficiente. Además, el riesgo de utilizar información desactualizada o incorrecta puede comprometer la calidad de la investigación. Una solución efectiva para estos problemas es la implementación de una wiki. Una wiki es una herramienta colaborativa online que permite la creación y edición de documentos de manera sencilla y organizada. Entre las ventajas de una wiki se encuentran la centralización de la información, la facilidad para buscar y acceder a datos, la colaboración en tiempo real, el historial de versiones para rastrear cambios y la posibilidad de comunicación y discusión en torno a los documentos. Para crear una wiki, existen varias herramientas recomendadas. Notion es una opción fácil de usar, aunque de pago. Google Suite es gratuita y conocida, aunque puede requerir más trabajo para enlazar documentos. Microsoft Office Online es similar a Google Suite, pero requiere una licencia. MediaWiki es una herramienta potente y open source, pero requiere conocimientos técnicos para su instalación. Finalmente, Obsidian es una opción avanzada, pero más compleja de implementar. Esperamos que este episodio te haya sido útil y te invitamos a seguir explorando maneras de mejorar la organización de la información en tu grupo de investigación. Finalmente, te invito a reflexionar sobre cómo aplicarías estas estrategias y a unirte libremente a nuestra comunidad de investigadores para discutir más sobre este tema a través del siguiente enlace: ⁠⁠https://chat.whatsapp.com/BIfSH9QFEiK9hiS83fw2am O también me puedes contactar directamente aquí: ⁠http://horacio-ps.com/contacto/⁠ --- Send in a voice message: https://podcasters.spotify.com/pod/show/horacio-ps/message

If your IT and security teams think malware is bad, wait until they learn about everything else.In 2024, the modern cyberattack is a segmented, prolonged, and professional effort, in which specialists create strictly financial alliances to plant malware on unsuspecting employees, steal corporate credentials, slip into business networks, and, for a period of days if not weeks, simply sit and watch and test and prod, escalating their privileges while refraining from installing any noisy hacking tools that could be flagged by detection-based antivirus scans. In fact, some attacks have gone so "quiet" that they involve no malware at all. Last year, some ransomware gangs refrained from deploying ransomware in their own attacks, opting to steal sensitive data and then threaten to publish it online if their victims refused to pay up—a method of extracting a ransom that is entirely without ransomware. Understandably, security teams are outflanked. Defending against sophisticated, multifaceted attacks takes resources, technologies, and human expertise. But not every organization has that at hand. What, then, are IT-constrained businesses to do? Today, on the Lock and Code podcast with host David Ruiz, we speak with Jason Haddix, the former Chief Information Security Officer at the videogame developer Ubisoft, about how he and his colleagues from other companies faced off against modern adversaries who, during a prolonged crime spree, plundered employee credentials from the dark web, subverted corporate 2FA protections, and leaned heavily on internal web access to steal sensitive documentation. Haddix, who launched his own cybersecurity training and consulting firm Arcanum Information Security this year, said he learned so much during his time at Ubisoft that he and his peers in the industry coined a new, humorous term for attacks that abuse internet-connected platforms: "A browser and a dream." "When you first hear that, you're like, 'Okay, what could a browser give you inside of an organization?'" But Haddix made it clear: "On the internal LAN, you have knowledge bases like SharePoint, Confluence, MediaWiki. You have dev and project management sites like Trello, local Jira, local Redmine. You have source code managers, which are managed via websites—Git, GitHub, GitLab, Bitbucket, Subversion. You have repo management, build servers, dev platforms, configuration, management platforms, operations, front ends. These are all websites."Tune in today. You can also find us on Apple Podcasts, Spotify, and Google Podcasts, plus whatever preferred podcast platform you use.For all our cybersecurity coverage, visit Malwarebytes Labs at malwarebytes.com/blog.Show notes and credits:Intro Music: “Spellbound” by Kevin MacLeod (incompetech.com)Licensed under Creative Commons: By Attribution 4.0 Licensehttp://creativecommons.org/licenses/by/4.0/Outro Music: “Good God” by Wowa (unminus.com)LLM Prompt Injection Game: https://gandalf.lakera.ai/Overwhelmed by modern cyberthreats? ThreatDown can...

Leaguepedia is a MediaWiki instance that covers tournaments, teams, and players in the League of Legends esports community. It's relied on by fans, analysts, and broadcasters from around the world. Megan "River" Cutrofello joined Leaguepedia in 2014 as a community manager and by the end of her tenure in 2022 was the lead for Fandom's esports wikis. She built up a community of contributing editors in addition to her role as the primary MediaWiki developer. She writes on her blog and is a frequent speaker at the Enterprise MediaWiki Conference Topics covered: When to use MediaWiki Visual vs code editor MediaWiki's rough syntax Templates and markup Limiting user input to simplify pages Choosing not to transliterate long player names in certain languages Handling mobile clients Building aliases for search results Creating a single source of truth Roster changes and caching Cargo (Query data in MediaWiki templates using SQL) Hiding implementation details from editors Optimizing for the editor, not a clean codebase Training your users to use workarounds MediaWiki only supports es5 The wiki aesthetic Who is working on the wiki + onboarding Who is using the wiki The future of Leaguepedia How Megan got into wiki development Issues as opportunities to onboard Related Links River Writes - Megan's Blog Leaguepedia - League of Legends esports wiki MediaWiki VisualEditor VueJS in MediaWiki Open issue to support ES6 in MediaWiki Whitespace programming language Lua MediaWiki extensions CharInsert - Add code snippets into the MediaWiki editor Semantic MediaWiki (SMW) - Store and query data inside Wiki pages Cargo - Replaced SMW at Leaguepedia Conference Talks Usage of Cargo with Lua on LoL Gamepedia Mediawiker SublimeText plugin Cargo/Lua Best Practices, and When Not To Use Them MediaWiki Lua Tutorial Editing your wiki with Python is easier than you think Other podcast appearances Between the Brackets Transcript You can help edit this transcript on GitHub. [00:00:00] Jeremy: Today I'm talking to Megan Cutrofello. She managed the Leaguepedia eSports wiki for eight years, and in 2017 she got an award for being the unsung hero of the year for eSports. So Megan, thanks for joining me today. [00:00:17] Megan: Thanks for having me. [00:00:19] Jeremy: A lot of the people I talk to are into web development, so they work with web frameworks and things like that. And I guess when you think about it, wikis are web development, but they're kind of their own world, I suppose. for someone who's going to build some kind of a site, like when does it make sense for them to use a wiki versus, uh, a content management system or just like a more traditional web framework? [00:00:55] Megan: I think it makes the most sense to use a wiki if you're going to have a lot of contributors and you don't want all of your contributors to have access to your server. also if your contributors aren't necessarily as tech savvy as you are, um, it can make sense to use a wiki. if you have experience with MediaWiki, I guess it makes sense to use a Wiki. Anytime I'm building something, my instinct is always, oh, I wanna make a Wiki (laughs) . Um, so even if it's not necessarily the most appropriate tool for the job, I always. My, my first thought is, hmm, let's see, I'm, I'm making a blog. Should I make my blog in in MediaWiki? Um, so, so I always, I always wanna do that. but I think it's always, when you're collaborating is pretty much, you always wanna do MediaWiki [00:01:47] Jeremy: And I, I think that's maybe an important point when you say people are collaborating. When I think about Wikis, I think of Wikipedia, uh, and the fact that I can click the edit button and I can see the markup right there, make a change and, and click save. And I didn't even have to log in or anything. And it seems like that workflow is built into a wiki, but maybe not so much into your typical CMS or WordPress or something like that. [00:02:18] Megan: Yeah. Having a public ability to solicit contributions from anyone. so for Leaguepedia, we actually didn't have open contributions from the public. You did have to create an account, but it's still that open anyone can make an account and all you have to do is like, go through that one step of create an account. Admittedly, sometimes people are like, I don't wanna make an account that's so much work. And we're like, just make the account. Come on. It's not that hard. but, uh, you still, you're a community and you want people to come and contribute ideas and you want people to come and be a part of that community to, document your open source project or, record the history of eSports or write down all of the easter eggs that you find in a video game or in a TV show, or in your favorite fantasy novels. Um, and it's really about community and working together to create something where the whole is bigger than the sum of its parts. [00:03:20] Jeremy: And in a lot of cases when people are contributing, I've noticed that on Wikipedia when you edit, there's an option for a, a visual editor, and then there's one for looking at the raw markup. in, in your experience, are people who are doing the edits, are they typically using the visual editor or are they mostly actually editing the, the markup? [00:03:48] Megan: So we actually disabled the Visual editor on Leaguepedia, because the visual editor is not fantastic at knowing things about templates. Um, so a template is when you have one page that gets its content pulled into the larger page, and there's a special syntax for that, and the visual editor doesn't know a lot about that. Um, so that's the first reason. And then the second reason is that, there's this, uh, one extension that we use that allows you to make a clickable, piece of text. It's called (https://www.mediawiki.org/wiki/Extension:CharInsert) CharInserts, uh, for character inserts. so I made a lot of these things that is sort of along the same philosophy as Visual Editor, where it's to help people not have to have the same burden of knowledge, of knowing every exact piece of source that has to be inserted into the page. So you click the thing that says like, um, insert a pick and band prefill, and then a little piece of JavaScript fires and it inserts a whole bunch of Wiki text and then you just enter the champions in the correct places. In the prefills of champions are like the characters that you play in, uh, league of Legends. And so then you have like the text is prefilled for you and you only have to fill in into this outline. so Visual Editor would conflict with CharInserts, and I much preferred the CharInserts approach where you have this compromise in between the never interacting with source and having to have all of the source memorized. So between the fact that Visual Editor like is not a perfect tool and has these bugs in it, and also the fact that I preferred CharInserts, we didn't use Visual Editor at all. I know that some wikis do like to use Visual Editor quite a bit, and especially if you're not working with these templates where you have all of these prefills, it can be a lot more preferred to use Visual Editor. Visual Editor is an experience much more similar to editing something like Microsoft Word, It doesn't feel like you're editing code. and editing code is, I mean, it's scary. Like for, and when I said like, MediaWiki is when you have editors who aren't as tech savvy, as the person who set up the Wiki. for people who don't have that experience, I mean, when you just said like you have to edit a wiki, like someone who's never done that before, they can be very intimidated by it. And you're trying to build a sense of community. You don't want to scare away your potential editors. You want everyone to be included there. So you wanna do everything possible to make everyone feel safe, to contribute their ideas to the Wiki. and if you make them have to memorize syntax, like even something that to me feels as simple as like two open brackets and then the name of a page, and then two closed brackets means linking the page. Like, I mean, I'm used to memorizing a lot of syntax because like, I'm a programmer, but someone who's never written code before, I mean, they're not used to memorizing things like that. So they wanna be able to click a button that says insert link, and then type the name of the page in the middle of the things that pop up there. Um, so visual editor is. It's a lot safer to use. so a lot of wikis do prefer that. and if it, if it didn't have the bugs with the type of editing that my Wiki required, and if we weren't using CharInserts so much, we definitely would've gone for it. But, um, it wasn't conducive to the wiki that I built, so we didn't use it at all. [00:07:42] Jeremy: And the, the compromise you're referring to, is it where the editor sees the raw markup, but then they can, there's like little buttons on the side they can click and they'll know, okay, if I click this one, then it's going to give me the text for creating a list or something like that. [00:08:03] Megan: Yeah, it's a little bit more high level than creating a list because I would never even insert the raw syntax for creating a list. It would be a template that's going to insert a list at the very end. but basically that, yeah, [00:08:18] Jeremy: And I, I know for myself, even though I do software development, if I click at it on a wiki and there's all the different curly brace tags, there's the square tags, and. I think if you spend some time with it, you can kind of get a sense of what it means. But for the average person who doesn't work with software in their day to day, do, do you find that, is that a big barrier for them where they, they click edit and there's all this stuff that they don't really understand? Is that where some people just, they go, oh, I don't, I don't know what to do. [00:08:59] Megan: I think the biggest barrier is actually clicking at it in the first place. so that was a big barrier to me actually. I didn't wanna click at it in the first place, and I guess my reasons were maybe a little bit different where for me it was like, I know that if I click edit, this is going to be a huge rabbit hole and I'm going to learn way too much about wikis and this is going to consume my entire life and look where I ended up. So I guess I was pretty right about that. I don't know if other people feel the same way or if they just like, don't wanna get involved at all. but I think once people, click edit, they're able to figure it out pretty well. I think there's, there's two barriers or maybe three barriers. the first one is clicking edit in the first place. The second one is if they learn to code templates at all. Media Wiki syntax is literally the worst I have encountered other than programming languages that are literally parodies. So like the white space language is worse (laughs https://en.wikipedia.org/wiki/Whitespace_(programming_language)) , but like it's two curly braces for a template and it's three curly braces for a variable. And like, are you actually kidding me? One of my blog posts is like a plea to editors to write a comment saying the name of the template that they're ending because media wiki like doesn't provide any syntax for what you're ending. And there's no, like, there's no indentation. So you can't visually see what you're ending. And there's no. So when I said the white sp white space language, that was maybe appropriate because MediaWiki prints all of the white space because it's really just like, PHP functions that are put into the text that you're literally putting onto the page. So any white space that you put gets printed. So the only way to put white space into your code is if you comment it out. So anytime you wanna put a new line, you have to comment out your new line. And if you wanna indent your code, you have to comment out the indents. So it's just, I, I'm , I'm not exaggerating here. It's, it's just the worst. Occasionally you can put a little bit of white space. Because there's like some divisions in parser functions that get handled when it gets sent to the parser. And, but I mean, for the most part it's just, it's just terrible. so if I'm like writing an if statement, I'll write if, and then I'll write a commented out endif at the end, so once an editor starts to write templates, like with parser functions and stuff, that's another big barrier because, and that's not because like people don't know how to code, it's just because the MediaWiki language, and I use language very loosely, it's like this collection of PHP functions poured into this just disaster It's just, it's not good! (laughs) And the, the next barrier is when people start to jump to Lua, which is just, I mean, it's just Lua where you can write Lua modules and then, Lua is fine. It's great, it has white space and you can make new lines and it's absolutely fine and you can write an entire code base and as long as you're writing Lua, it's, it's absolutely fantastic and there's nothing wrong with it anymore (laughs) So as much as I just insulted the MediaWiki language, like writing Lua in MediaWiki is great (laughs) . So for, for most of my time I was writing Lua. Um, and I have absolutely no complaints about that except that Lua is one index, but actually the one indexing of Lua is fine because MediaWiki itself is one indexed. So people complain about Lua being one index, and I'm like, what are you talking about? If it's, if another language were used, then you'd have all of this offsetting when you go to your scripting language because you'd have like the first argument from your template in MediaWiki going into your scripting language, and then you'd have to offset it to zero and everyone would be like vastly confused about what's going on. So you should be thankful that they picked a language that's one index because it saves you all of this headache. So anyway, sorry for that tangent, but it's very good that we picked a one index language. [00:13:17] Jeremy: When you were talking about the, the if statement and having to put in comments to have white space, is it, cuz like when I think about an if statement in most languages, the, the if statement isn't itself rendering anything, it's like deciding if you're going to do something inside of the, if so. like what, what would that white space do if you didn't comment it out in the context of the if? [00:13:44] Megan: So actually you would be able to put some white space inside of an if statement, but you would not be able to put any white space after an if statement. and there, most likely inside of the if statement, you're printing variables or putting other parser functions. and the other parser functions also end in like two curly braces. And, depending on what you're printing, you're likely ending with a series of like five or eight, or, I don't know, some very large set of curly braces. And so what I like to do is I would like to be able to see all of the things that I'm ending with, and I wanna know like how far the nesting goes, right. So I wanna write like an end if, and so I have to comment that out because there's no like end if statement. so I comment out an end if there, it's more that you can't indent the statements inside of the if, because anything that you would be printing inside of your code would get printed. So if I like write text inside of the code, then that indentation would get printed into the page. And then if I put any white space after the if statement, then that would also get printed. So technically you can have a little bit of white space before the curly braces, but that's only because it's right before the curly braces and PHP will strip the contents right inside of the parser function. So basically if PHP is stripping something, then you're allowed to have white space there. But if PHP isn't stripping anything, then all of the white space is going to be printed and it's like so inconsistent that for the most part it's not safe to put white space anywhere because you don't, you have to like keep track of am I in a location where PHP is going to be stripping something right now or not? and I, I wanna know what statement or what variable or what template I'm closing at any location. So I always want to, write out what I'm closing everywhere. And then I have to comment that because there was no foresight to put like an end if clause in this white space, sensitive language. [00:16:22] Jeremy: Yeah, I, I think I see what you mean. So you have, if you're gonna start an, if you have the, if inside these curly braces, but then, inside the, if you typically are going to render some text to the page, and so intuitively you would indent it so that it's indented in from the if statement. But then if you do that, then it's gonna be shifted to the right on, on the Wiki. Did I get that right? [00:16:53] Megan: Yeah. So you have the flexibility to put white space immediately because PHP will strip immediately, but then you don't have flexibility to put any white space after that, if that makes sense. [00:17:11] Jeremy: So, so when you say immediately, is that on the following line or is that [00:17:15] Megan: yeah, so any white space before the first clause, you have flexibility. So like if you were to put an if statement, so it's like if, and then there's a colon, all of the next white space will get stripped. Um, so then you can put some text, but then, if you wanted to like put some text and then another if statement nested within the first if statement. It's not like Lua where you could like assign a variable and then put a comment and then put some more white space and then put another statement. And it's white space insensitive because you're just writing code and you haven't returned anything yet. it, it's more like Jinja (View templating language) than Python for, for an analogy. So everything is getting printed because you're in like a, this templating language, not actually a programming language. Um, so you have to work as if you're in a templating language about, you know, 70% of the time , unless you're in this like very specific location where PHP is stripping your white space because you're at the edge of an argument that's being sent there. So it's like incredibly inconsistent. And every now and then you get to like, pretend that you're in an actual language and you have some white space, that you can indent or whatever. it's just incredibly inconsistent, which is like what you absolutely want out of a programming language (laughs) yeah, it's like you're, you're writing templates, but like, it seems like because of the fact that it's using php, there's [00:18:56] Jeremy: weird exceptions to the behavior. Yeah. [00:18:59] Megan: Exactly. Yeah. [00:19:01] Jeremy: and then you also mentioned these, these templates. So, if I understand correctly, this is kind of like how a lot of web frameworks will have, partials, I guess, where you'll, you'll be able to have a webpage, but it's made up of different I don't know if you would call them components, but you're able to build a full page that's made up of a bunch of different pieces. So you could have a [00:19:31] Megan: Yeah Yeah that's a good analogy. [00:19:33] Jeremy: Where it's like, here's my table of contents, or here's my info box, or things like that. And those are all things that you would create a MediaWiki template for, and then somehow the, the data gets passed into those templates and the template decides how to, to render it out. [00:19:55] Megan: Yeah. [00:19:56] Jeremy: And for these, these templates, I, I noticed on some of the Leaguepedia pages, I noticed there's some html in some of them. I was curious if that's typical to write them with HTML or if there are different ways native to Media Wiki for, for, creating these templates. [00:20:23] Megan: Um, it depends on what you're doing. MediaWiki has a special syntax for tables specifically. I would say that it's not necessarily recommended to use the special syntax because occasionally you can get things to not work out fantastically if people slightly break things. But it's easier to use it. So if you know that everything's going to work out perfectly, you can use it. and it's a simple shortcut. if you go to the help page about tables on Wikipedia, everything is explained, and not all HTML works, um, for security reasons. So there's like a list of allowed, things that you can use, allowed tags, so you can't put like forms and stuff natively, but there's the widgets extension that you can use and widgets just automatically renders all html that you put inside of a widget. Uh, and then the security layer there is that you have to have a special permission to edit a widget. so, you only give trusted people that permission and then they can put the whatever html they want there. So, we have a few forms on Leaguepedia that are there because I edited, uh, whichever widgets, and then put the widgets into a Lua module and then put the Lua module into a template and then put the template onto the page. I was gonna say, it's not that complicated. It's not as complicated as it sounds, but I guess it really is as complicated as it sounds (laughs) . Um, so, uh, I, I won't say that. I don't know how standard it is on other wikis to use that much html, I guess Leaguepedia is pretty unique in how complicated it is. There aren't that many wikis that do as many things as we did there. but tables are pretty common. I would say like putting divs places to style them, uh, is also pretty common. but beyond that, usually there's not too many HTML elements just because you typically wanna be mobile friendly and it's relatively hard to stay mobile friendly within the bounds of MediaWiki if you're like putting too many elements everywhere. And then also allowing users to put whatever content inside of them that they want. The reason that we were able to get away with it is because despite the fact that we had so many editors, our content was actually pretty limited. Like if there's a bracket, it's only short team names going into it. So, and short team names were like at most five or six characters long, so we don't have to worry about like overflow of team names. Although we designed the brackets to support overflow of team names, and the team names would wrap around and the bracket would not break. And a lot of CSS Magic went into making that work that, we worked really hard on and then did not end up using (laughsz) [00:23:39] Jeremy: Oh no. [00:23:41] Megan: Only short team names go into brackets. But, that's okay. uh, and then for example, like in, uh, schedules and stuff, a lot of fields like only contain numbers or only contain timestamps. there's like a lot of tables again where like there's only two digit numbers with one decimal point and stuff like that. So a lot of the stuff that I was designing, I knew the content was extremely constrained, and if it wasn't then I said, well, too bad. This is how I'm telling you to put the content . Um, and for technical reasons, that's the content that's gonna go here and I don't care. so there's like, A lot of understanding that if I said for technical reasons, this is how we have to do it. Then for technical reasons, that was how we had to do it. And I was very lucky that all of the people that I worked with like had a very big appreciation with like, for technical reasons, like argument over. This is what's happening. And I know that with like different people on staff, like they would not be willing to compromise that way. Um, so I always felt like extremely lucky that like if I couldn't figure out a way to redesign or recode something in order to be more flexible, then like that would just be respected. And that was like how we designed something. But in general, like it's, if you are not working with something as rigid as, I mean, and like the history of eSports sounds like a very fluid thing, but when you think about it, like it's mostly names of teams, names of players and statistics. There's not that much like variable stuff going on with it. It's very easy to put in relational databases. It's very easy to put in fixed width tables. It's very easy to put in like charts that look the same on every single page. I'm not saying. It was always easy to like write everything that I wrote, and it's not, it wasn't always easy to like, deal with designs and stuff, but like relative to other topics that you can pick, it was much easier to put constraints on what was going to go where because everything was very similar across regions, across, although actually one thing. Okay, so this will be like the, the exception that proves the rule. uh, we would trans iterate players' names when we, showed them in team rosters. So, uh, for example, when we were showing the hangul, the Korean player's names, we would show an English translation also. Um, and we would do this for every single alphabet. but Hungarian players' names are really, really, really long. And so the transliteration doesn't fit in the table when we show the translation to the Roman alphabet. And so we couldn't do this, so we actually had to make a cargo table. Of alphabets that are allowed to be transliterated into the Roman alphabet, uh, when we have players names in that alphabet. So we had, like, hangul was allowed and Arabic was allowed, and I can't remember the exact list, but we had like three alphabet, three or four alphabets were allowed and the rest of the alphabets were dis allowed to be transliterate into, uh, the Roman alphabet. and so again, we made up a rule that was like a hard rule across the entire Wiki where we forced the set of alphabets that were transliterated so that this tables could be the same size roughly across every single team page because these Hungarian player names are too long (laughs) So I guess even this exception ended up being part of the rule of everything had to be standardized because these tables were just way too wide and they were running into the info box. They couldn't fit on the side. so it's really hard when you have like arbitrary user entered content to fit it into the HTML that you design. And if you don't have people who all agree to the same standards, I mean, Even when we did have people who agreed to all of the same standards, it was really, really, really hard. And we ended up having things like a table of which alphabets to transliterate. Like that's not the kind of thing that you think you're going to end up having when you say, let's catalog the history of League of Legends eSports, [00:28:40] Jeremy: And, and so when, let's say you had a language that you couldn't trans iterate, what would go into the table. [00:28:49] Megan: uh, just the native alphabet. [00:28:51] Jeremy: Oh I see. Okay. [00:28:53] Megan: Yeah. And then if they went to the player page, then you would be able to see it transliterated. But it wouldn't show up on the team page. [00:29:00] Jeremy: I see. And then to help people visualize what some of these things you're talking about look like when you're talking about a, a bracket, it's, is it kind of like a tree structure where you're showing which teams are facing which teams and okay, [00:29:19] Megan: We had a very cool, CSS grid structure that used like before and after pseudo elements to generate the lines, uh, between the teams and then the teams themselves were the elements of the grid. Um, and it's very cool. Uh, I didn't design it. Um, I have a friend who I very, very fortunately have a friend who's amazing at CSS because I am like mediocre at css and she did all of our CSS for us. And she also like did most of our designs too. Uh, so the Wiki would not be like anything like what it is without her. [00:30:00] Jeremy: And when you're talking about making sure the designs fit on desktop and, and mobile, um, I think when you were talking earlier, you're talking about how you have these, these templates to build these tables and the, these, these brackets. Um, so I guess in which part of the wiki is it ensuring that it looks different or that it fits when you're working with these different screen sizes [00:30:32] Megan: Usually it's a peer CSS solution. Every now and then we hide an element on mobile altogether, and some of that is actually MediaWiki core, for example, in, uh, nav boxes don't show up on mobile. And that's actually on Wikipedia too. Uh, well, I guess, yeah. I mean, being MediaWiki core, So if you've ever noticed the nav boxes that are at the bottom of pages on Wikipedia, just don't show up on like en.m.wikipedia.org. and that way you're not like loading, you're not loading, but display noneing elements on mobile. but for the most part it's pure CSS Solutions. Um, so we use a lot of, uh, display flex to make stuff, uh, appropriate for mobile. Um, some media roles. sometimes we display none stuff for mobile. Uh, we try to avoid that because obviously then mobile users aren't getting like the full content. Occasionally we have like overflow rules, so you're getting scroll bars on mobile and then every now and then we sort of just say, too bad if you're on mobile, you're gonna have not the greatest solution or not the greatest, uh, experience. that's typically for large data tables. so the general belief at fandom was like, if you can't make it a good experience on mobile, don't put it on the Wiki. And I just think that's like the worst philosophy because like then no one gets a good experie. And you're just putting less content on the Wiki so no one gets to enjoy it, and no one gets to like use the content that could exist. So my philosophy has always been like the, the, core overview pages should be, as good as possible for both PC and mobile. And if you have to optimize for one, then you slightly optimize for mobile because the majority of traffic is mobile. but attempt not to optimize for either one and just make it a good experience on both. but then the pages behind that, I say behind because we like have tabs views, so they're like sort of literally behind because it looks like folders sort of, or it looks like the tabs in a folder and you can, like, I, I don't know, it, it looks like it's behind (laughs) , the, the more detailed views where it's just really hard to design for mobile and it's really easy to design for pc and it just feels very unlikely that users on mobile are going to be looking at these pages in depth. And it's the sort of thing. A PC user is much more likely to be looking at, and you're going to have like multiple windows open and you're gonna be tapping between them and you're gonna be doing all of your research at PC. You absolutely optimize this for PC users. Like, what the hell this is? These are like stats pages. It's pages and pages and pages of stats. It's totally fine to optimize this for PC users. And if the option is like, optimized for PC users or don't create it at all, what are you thinking To not create it at all, like make it a good experience for someone? So I don't, I don't understand that philosophy at all. [00:34:06] Jeremy: Did you, um, have any statistics in terms of knowing on these types of pages, these pages that are information dense or have really big tables? Could you tell that? Oh, most of the people coming here are on computers or, or larger screens. [00:34:26] Megan: I didn't have stats for individual pages. Um, mobile I accidentally lost Google Analytics access at some point, and honestly I wasn't interested enough to go through the process of trying to get it back. when I had it, it didn't really affect what I put time into, because it was, it was just so much what I expected it to be. That it, it didn't really affect much. What I actually spent the most time on was looking, so you can, uh, you get URLs for search results. And so I would look through our search results, and I would look at the URL of the failed search results and, so there would be like 45 results for this particular failed search. And then I would turn that into a redirect for what I thought the target was supposed to be. So I would make sure that people's failed searches would actually resolve to the correct thing. So if they're like typo something, then I make the typo actually resolve. So we had a lot of redirects of like common typos, or if they're using the wrong name for a tournament, then I make the wrong name for the tournament resolve. So the analytics were actually really helpful for that. But beyond that, I, I didn't really find it that useful. [00:35:48] Jeremy: And then when you're talking about people searching, are these people using a search box on the Wiki itself And not finding what they were looking for? [00:36:00] Megan: Yeah. So like the internal search, so like if you search Wikipedia for like New York City, but you spell it C I Y T, , then you're not going to get a result. But it might say, did you mean New York City t y? If like 45 people did that in one month, then that would show up for me. And then I don't want them to be getting, like, that's a bad experience. Sure. They're eventually getting there, but I mean, I don't want them to have to spend that extra time. So I'm gonna make an automatic redirect from c Y T to c i t Y [00:36:39] Jeremy: And, and. Maybe we should have talked about this a little earlier, but the, all the information on Leaguepedia is, it's about all of the different matches and players, um, who play League of Legends. so when you edit a, a page on Wikipedia, all of that information, or a lot of it I think is, is hand entered by, by people and on Leagueapedia, which has all this information about like what, how teams did in a tournament or, intricate stats about how a game went. That seems like a lot of information for someone to be hand entering. So I was wondering how much of that information is somebody actually manually editing those things and how much is, is done automatically or programmatically. [00:37:39] Megan: So it's mostly hand entered. We do have a little bit of it that's automated, via a couple scripts, but for the most part it's hand entered. But after being handed, entered into a couple of data pages, it gets propagated a lot of times based on a bunch of Lua modules and the cargo extension. So when I originally joined the Wiki back in 2014, it was hand entered. Not just once, but probably, I don't know, seven times for tournament results and probably 10 or 12 times for roster changes. It was, it was a lot. And starting in 2017, I started rewriting all of the code so that it was entered exactly one time for everything. Tournament results get entered one time into a data page and roster changes get entered one time into a data page. And, for roster changes, that was very difficult because, for a roster change that needs to update the team history on a player page, which goes, from a join to a leave and it needs to update the, the like roster, change portal for the off season, which goes from a leave to a join because it's showing like the deltas over the off season. And it needs to update the current team in the, player's info box, which means that the current team has to be calculated from all of the deltas that have ever occurred in that player's history and it needs to update. Current rosters in the team pages, which means that the team page needs to know all of the current players who are currently on the team, which again, needs to know all of the deltas from all of history because all that you're entering is the roster changes. You're not entering anyone's current team. So nowhere on the wiki does it ever store a current team anymore. It only stores the roster changes. So that was a lot of code to write and deciding even what was going to be entered was a lot because, all I knew was that I was going to single source of truth that somehow and I needed to decide what was I going to single source of truth. So I decided, um, that I was going to be this Delta and then deciding what to do with that, uh, how to store it in a relational database. It was, it was a big project. and I didn't have a background as a developer either. so this was like, I don't know, this was like my third big project ever. So, that was, that was pretty intense. but it was, it was a lot of fun. so it is hand entered but I feel like that's underselling it a little bit. [00:40:52] Jeremy: Yeah, cuz I was initially, I was a little confused when you mentioned how somebody might need to enter the same information multiple times. But, if I understood correctly, it would be if somebody's changing which team they're on, they would have to update, for example, the player's page and say like, oh, this player is on this team now. And then you would have to go to their old team and remove them from the roster there. Go to the new team, add them to the roster there, And you can see where it would kind [00:41:22] Megan: Yeah. And then there's the roster, there's the roster nav box, and there's like the old team, you have to say, like the next team. Cuz in the previous players list, like we show former team members from the old team and you have to say like the next team. Uh, so if they had like already left their old team, you'd have to say like, new team. Yeah, there's a, there's a lot of, a lot of places. [00:41:50] Jeremy: And so now what it sounds like is, I'm not sure this is exactly how it works, but if you go to any location that would need that information, which team is this player on? When you go to that page, for example, if you were to go to, uh, a teams page, then it would make a SQL query to figure out I guess who most recently had a, I forget what you called it, but like a join row maybe, or like a, they, they had the action of joining this team, and now, now there's a row in the database that says they did this. [00:42:30] Megan: it actually looks at the ten-- so I have an in in between table called tenures. And so it looks at the tenures table instead of querying all the way through the joins and leaves table and doing like the whole list of deltas. yeah. So, and it's also cached so you, it doesn't do the SQL query every time that you load the page. So the only time that the SQL queries actually happen is if you do a save on the page. And then otherwise the entire generated HTML of the page is actually cached on the server. So you're, you're not doing that many database queries every time you load the page, so don't worry about that. but there, there can actually be something like a hundred SQL queries sometimes, when you're, saving a page. So it would be absolute murder if you were doing that every time you went to the page. But yeah, it works. Something like that. [00:43:22] Jeremy: Okay, so this, this tenures table is, that's kind of like what's the current state of all these players and where they are, and then. [00:43:33] Megan: Um, the, the tenures table, caches sort of, or I guess the tenure table captures is a better word than caches um, every, join to leave historically from every team. Um, and then I save that for two reasons. The first one is so that I don't have to recompute it, uh, when I'm doing the team's table, because I have to know both the current members and the former members. And then the second reason is also that we have a public api and so people can query that. if they're building tools, like a lot of people use the public api, uh, for various things. And, one person built like, sort of like a six degrees of Kevin Bacon except for League of Legends, uh, using our tenures tables. So, part of the reason that that exists is so that uh, people can use it for whatever projects that they're doing. Cause the join, the join leave table is like pretty unfriendly and I didn't wanna have to really document that for anyone to use. So I made tenures so that that was the table I could document for people to use. [00:44:39] Jeremy: Yeah. That, that's interesting in that, yeah, when you provide an api, then there's so many different things people can do that even if your wiki didn't really need it, they can build their own apps or their own pages built on all this information you've aggregated. [00:44:58] Megan: Yeah. It's nice because then when someone says like, oh, can you build this as a feature request? I can say no, but you can (laughs) [00:45:05] Jeremy: Well you've, you've done the, the hard part for them (laughs) [00:45:09] Megan: Yeah. exactly. [00:45:11] Jeremy: So that's cool. Yeah. that's, that's interesting too about the, the caching because yeah, I guess when you think about a wiki, most of the people who are visiting it are just visiting it to see what's on there. So the, provided that they're not logged in and they don't need anything specific to them. Yeah, you should be able to cache the whole response. It sounds like. [00:45:41] Megan: Yeah. yeah. Caching was actually a nightmare with this in this particular thing. the, the team roster changes, because, so cargo, which I mentioned a couple times is the database extension that we used. Um, and it's basically a SQL wrapper that like, doesn't port 80% of the features that SQL has. so you can create tables and you can query, but you can't make, uh, like sub-select queries. So your queries have to be like very simple. which is good for like most users of MediaWiki because like the average MediaWiki user doesn't have that much coding experience, but if you do have coding experience, then you're like, what, what, what am I doing? I can't, I can't do anything. Um, but it's a very powerful tool, still compared to most of what you could do with Media Wiki without this, basically you're adding a database layer to your software stack, which I mean, I, I, that's what you're doing, (laughs) Um, so you get a huge amount of power from adding cargo to a wiki. Um, in exchange it's, it's very performance. It's like, it's, it, it's resource heavy. uh, it hurts your performance a lot. and if you don't need it, then you shouldn't use it. But frequently you need it when you're doing, difficult or not necessarily difficult, but like intensive things. Um, anytime that you need to pull data from one page to another, you wanna use something like that. Um, So cargo, uh, one of the things that it doesn't do is it doesn't allow you to, uh, set a primary key easily. so you have to like, just like pretend that one row in the table is your primary key, basically. it internally automatically sets one, but it won't be static or it won't be the same every time that you rebuild the table because it rebuilds the table in a random order and it just uses an auto increment primary key. So you set a row in the table to pretend to be your ran, to pretend to be your primary key. But editors don't know what, your editors don't understand anything about primary keys. And you wanna hide this from them completely. Like, you cannot tell an editor, protect this random number, please don't change this. So you have to hide it completely. So if you're making your own auto increment, like an editor cannot know that that exists. Like this is back to when we were talking about like visual editor. This is like, one of the things about making the wiki safe for people is like not exposing them to the internals of like, anything scary like that. So for example, if an editor accidentally reorders two rows and your roster change data like that has to not matter. Because that can't break the entire wiki. They, you can't make an editor like freak out because they just reordered two rows in, in the page. And you can't put like a scary notice somewhere saying, under no circumstances reorder two rows here. Like, that's gonna scare people away. And you wanna be very welcoming and say like, it's impossible to break this page no matter how hard you tried. Don't worry. Anything you do, we can just fix it. Don't worry. But the thing is that everything's going to be cached. And so in particular, um, when I said I made that tenures table, one thing I did not wanna do was resave every single row from the join leave table. So you had to join back to, sorry, I'm going to use, join in two different connotations. you had to join back to the join leave table in order to get like all of the auxiliary data, like all of the extra columns, like, I don't know, like role, date, team name and stuff. Because otherwise the tenures table would've had like 50 columns or something. So I needed to store the fake primary key in the tenures table, but the tenures table is cached on the player page and the join leave table is on the data page, which means that I need to purge the cache on the player page anytime that someone edits the data on the data page. Which means that, so there's like some JavaScript that does that, but if someone like changes the order of the lines, then that primary key is going to change because I have an auto increment going on. And so I had to like very, very carefully pick a primary key here so that it was literally impossible for any kind of order change to affect what the primary key was so that the cash on the player page wasn't going to be changed by anything that the editor did in unless they were going to then update the cash on that player page after making that change. If that makes sense. So after an editor makes a change on the news page, they're going to press a button to update the cache on the player page, but they're only going to update the player page for the one line that they change on the news page. These, uh, primary keys had to be like super invariant for accidental row moves, or also later on, like entire moves of separating a bunch of these data pages into like separate subpages because the pages were getting too big and it was like timing out the server because there were too many stores to the database on a single page every time you save the page. And anyway, it took me like five iterations of making the primary key like more and more specific to the single line because my auto increment was like originally including every single line I was auto incrementing and then I auto incremented only when that single player was was involved. And then I auto incremented only when that player and the team was involved. And then I reset the auto increment for that date. So, and it was just got like more and more convoluted what my primary key was. It was, it was a mess. Anyway, this is just like another thing when you're working with volunteers who don't know what's going on and they're editing the page and they can contribute content, you have to code for the editor and not code for like minimizing complexity, The editor's experience matters more than the cleanliness of your code base, and you just end up with these like absolute messes that make no sense whatsoever because the editor's experience matters and you always have to code to the editor. And Media Wiki is all about community, and the editor just becomes part of the software and part of the consideration of your code base, and it's very, very different from any other kind of development because they're like, the UX is just built so deeply into how you're developing. [00:53:33] Jeremy: if I am following correctly, when I, when I think of using SQL when you were first talking about cargo and you were talking about how you make your own tables, and I'm envisioning the, the columns and the rows and, it's very common for the primary key to either be auto incrementing or some kind of GUID But then if I understood correctly, I think what you were saying is that anytime an editor makes changes to the data, it regenerates the whole table. Is that did I get that right? [00:54:11] Megan: It regenerates all of the rows on that page. [00:54:14] Jeremy: and when you talk about this, these data pages, there's some kind of media wiki or cargo specific markup where people are filling in what is going to go into the rows. And the actual primary key that's in MySQL is not exposed anywhere when they're editing the data. [00:54:42] Megan: That's right [00:54:44] Jeremy: And so when you're talking about trying to come up with a primary key, um, I'm trying to, I guess I'm trying to picture [00:54:57] Megan: So usually I do page name underscore an auto increment. But then if people can rearrange the rows which they do because they wanna get the rows chronological, but some people just put it at the top of the page and then other people are like, oh my God, it's not chronological. And then they fix it and then other people are like, oh my God, you messed up the time zone. And then they rearrange it again. Then, I mean, normally I wouldn't care because I don't really care like what the primary key is. I just care that it exists. But then because I have it cached on these player pages, I really, really do care what the primary key is. And because I need the primary key to actually agree with what it is on the data page, because I'm actually joining these things together. and people aren't going to be updating the cache on the player page if they don't think that they edited the row because rearranging isn't actually editing and people aren't going to realize that. And again, this is burden of knowledge. People can't, I can't make them know that because they have to feel safe to make any edits. It's bad enough that they have to know that they have to click this button to update the cache after making an edit in the first place. so, the auto increment isn't enough, so it has to be like an auto increment, but only within the set of rows that incorporate that one player. And then rearranging is pretty safe because they'd have to rearrange two pieces of news, including the same player. And that's really unlikely to happen. It's really unlikely that someone's going to flip the order of two pieces of news that involve the same player without realizing that they're actually are editing that single player except maybe they are. So then I include the team in that also. So they'd have to rearrange two pieces of news, including the same player and the same team. And that's like unlikely to happen in the first place. And then like, maybe a mistake happens like once a year. And at the end of the day, the thing that really saves us is that we're a wiki. We're not an official source. And so if we have a mistake once a year, like no one cares really. So we're not going for like five nines or anything. We're going for like, you know, two (laughs) . Um, so [00:57:28] Jeremy: so [00:57:28] Megan: We were having like mistakes constantly until I added player and team and date to the set of things that I was auto incrementing against. and once I got all of those, it was pretty stable. [00:57:42] Jeremy: And for the caching part, so when you're making a cargo query or a SQL query on one page and it needs to join on or get data from another page, it goes to this cache that you have instead of going directly to the actual table in the database. And the only way to get the right data is for the editor to click this button on the website that tells it to update the cache did I get that right? [00:58:23] Megan: Not quite. So it, well, or Yes, you did sort of, it goes to the actual table. The issue here is that, the table was last updated, the last time that a page was saved. And the last time the data got saved was the last time that the page that contains the parser function that generates those rows got saved. So, let me say that again. So, some of the data is being saved from the data page where the users manually enter it, and that's fine because the only time that gets updated is when the users manually enter it and then the page gets saved. But then these tenures tables are stored by my lua code on the player pages, and those aren't going to get updated unless the player page gets blank edited or null edited, or a save action happens from the player page. And so the way to make a, an edit happen from the player page is either to manually go there and click edit, and then click save, which is called a blank edit because. Blank edited, you didn't do anything but you pressed save or to use my JavaScript gadget, which is clicking a button from the data page that just basically does that for you using the api. And then that's going to update the table and then the database table, because that's where the, the cargo parser function is that writes to the database and updates the tables there. with the information, Hey, the primary key changed, because that's where the parser function is physically located in the wiki because one of them is on the data page and one of them is on the player page. So you get this disconnect in the cache where it's on two different pages and so you have to press a save action in both of them before the table is consistent again. [01:00:31] Jeremy: Okay. It be, it's, so this is really all about the tenure table, which the user will never mod or the editor will never modify directly. You need your code running on the data page and the player's page to run, to update the The tenure table? [01:00:55] Megan: Yeah, exactly. [01:00:57] Jeremy: yeah, it's totally hidden that this exists to the editor, but it's something that, that you as the person who put this all together, um, have to always be aware of, yeah. [01:01:11] Megan: Right. So there was just so many things like this, where you just had to press this one button. I call it refresh overview because originally it was on a tournament page and you had to press, the refresh overview button to purge the cache on the overview page of the tournament. after editing the data and you would refresh, overview, to deal with this cache lag. And everyone knew you have to refresh overview, otherwise none of your data entry is gonna like, be worth anything because it's not, the cache is just gonna lag. but every editor learned, like if there's a refresh overview button, make sure you press the refresh overview button, , otherwise nothing's gonna happen. Um, and there is just like tons of these littered across the Wiki. and like to most people, it just like, looks like a simple little button, but like so many things happen when you press this button. so it is, it is very important. [01:02:10] Jeremy: Are there, no ways inside of media wiki to if somebody edits one page, for example, to force it to go and, do, I forget what you called it, like a blank save or blank edit on another page? [01:02:27] Megan: So that wouldn't even really work because, we had 11,000 player pages. And you don't know which one the user just edited. so it, it's unclear to MediaWiki what just happened when the user just edited some part of the data page. and like the whole point here is that I can't even blank edit every single player page that the data page links to because the data page probably links to, I don't know, 200 different player pages. So I wanna link, I wanna blank it like the five that this one news line links to. so I do that, through like HTML attributes, in the JavaScript, [01:03:14] Jeremy: Oh, so that's why you're using JavaScript so that you can tell what the person edited because there isn't really a way to know natively in, in MediaWiki. what just changed? [01:03:30] Megan: there's like a diff so I could, like, MediaWiki knows the characters that got changed, but it doesn't really know like semantically what happened. So it doesn't know, like, oh, a link to this just got edited and especially because, I mean it's like templates that got edited, not really like the final HTML or anything. So Media Wiki has no idea what's going on. so yeah, so the JavaScript, uh, looks at the HTML attributes and then runs a couple API queries, and then the blank edits happen and then a couple purges after that so that the cache gets purged after the blank edit. [01:04:08] Jeremy: Yeah. So it, it seems like on these Wiki pages, you have the html, you have the CSS you have the ability to describe these data pages, which I, I guess in the end, end up being rows in in SQL. And then finally you have JavaScript. So it kind of seems like you can do almost everything in the context of a a Wiki page. You have so many, so many of these tools at your, at your disposal. [01:04:45] Megan: Yeah. Except write es6 code. [01:04:48] Jeremy: Oh, still, still only es5. [01:04:52] Megan: Yeah, [01:04:52] Jeremy: Oh no. do, do you know if that's something that they are considering changing or [01:05:01] Megan: There's a Phabricator ticket open. [01:05:05] Jeremy: How, um, how, how many years? [01:05:06] Megan: It has a lot of comments, oh a lot of years. I think it's since like 2014 or something [01:05:14] Jeremy: Oh yeah. I, I guess the, the one maybe, well now now the browsers all, all support es6, but I, I guess one of the things, it sounds like media wiki, maybe side stepped is the whole, front end ecosystem in, in terms of node packages and build tools and things like that. is, is that right? It's basically you can write JavaScript and there, yeah, [01:05:47] Megan: You can even write jQuery. [01:05:49] Jeremy: Oh, okay. That's built in as well. [01:05:52] Megan: Yeah .So I have to admit, like my, my front end knowledge is like a decade out of date or something because it's like what MediaWiki can do and there's like this entire ecosystem out there that I just like, don't have access to. And so I like barely know about. So I have this like side project that uses React that I've like, kind of sort of been working on. And so like I know this tiny little bit of react and I'm like, why? Why doesn't MediaWiki do this? Um, they are adding Vue support. So in theory I'll get to learn vue so that'll be fun. [01:06:38] Jeremy: So I'm, I'm curious, just from the limited experience you've had, outside of, MediaWiki, are, are there like specific things, uh, in your experience working with React where you're, you really wish you had in inside of Media Wiki? [01:06:55] Megan: Well, really the big thing is like es6, like I really wish we could use arrow functions , like that would be fantastic. Being able to build components would be really nice. Yeah, we can't do that. [01:07:09] Jeremy: I, I suppose you, you've touched a little bit on performance before, but I, I guess that's one thing about Wikis is that, putting what's happening in the back end, aside the, the front end experience of Wikis, they, they feel pretty consistent since they're generally mostly server rendered. And the actual JavaScript is, is pretty light, at least from, from Wikis I've seen. [01:07:40] Megan: Yeah. I mean you can add as much JavaScript as you want, so I guess it depends on what the users decide to do. But it's, it's definitely true that wikis tend to load faster than some websites that I've seen. [01:07:54] Jeremy: Yeah, I mean, I guess when you think of a wiki, it's, you're there cuz you wanna get specific information and so the goal is not to necessarily reproduce like some crazy complex app or something. It's, It's, to get you the, the, information. Yeah. [01:08:14] Megan: Yeah. No, that's actually one thing that I really like about Wikis also is that you don't have the pressure to make them look nice. I know that some people are gonna hear that and just like, totally cringe and be like, oh my God, what is she saying? ? Um, but it's actually really true. Like there's an aesthetic that Wikis and Media Wiki in particular have, and you kind of stick to that. And within that aesthetic, I mean, you make them look as nice as you can. Um, and you certainly don't wanna like, make them deliberately ugly, but there's not a pressure to like go over the top with like marketing and branding and like, you know, you, you just make them look reasonably nice. And then the focus is on the information and the focus is on making the information as easy to understand as possible. And a wiki that looks really nice is a wiki that's very understandable and very intuitive, and one where you. I mean, one, that the information is the joy and, you know, not, not the presentation, I guess. So it's like the presentation of the information instead of the presentation of the brand. so I, I really appreciate that about wikis. [01:09:30] Jeremy: Yeah, that's a good point about the aesthetics in the sense of like, they have a certain look and yeah, maybe it's an authoritative look, , which, uh, is interesting cuz it's, like a, a wiki that I'll, I'll commonly go to for example, is there's the, the PC gaming Wiki. And when you look at how it's styled, it feels like very dated or it doesn't look like, I guess you could say normal webpages, but it's very much in line with what you expect a wiki to look like. So it's, it's interesting how they have that, shared aesthetic, I guess. [01:10:13] Megan: Yeah. yeah. No, I really like it. The Wiki experience, [01:10:18] Jeremy: We, we kind of touched on this near the beginning, but sometimes when. I would see wikis and, and projects like Leaguepedia I would kind of wonder, you know, what's the decision between or behind it being a wiki versus something being like a custom CMS in, in the case of Leaguepedia but, you know, talking to you about how it's so, like wikis are structured so that people can contribute. and then like you were saying, you have like this consistent look that brings the data to the user. Um, I actually, it gives me a better understanding of why so many people choose wikis as, as ways to present this information. [01:11:07] Megan: Yeah, a a lot of people have asked me over the years why, why MediaWiki when it always feels like I'm jumping through so many hoops. Um, I mean, when I just described the caching thing to you, and that's just like one of, I don't know, dozens of struggles that I've had where, MediaWiki has gotten in the way of what I need to do. Because really Leaguepedia is an entire software layer on top of MediaWiki, and so you might ask why. Why MediaWiki? Why not just build the software layer on top of something easier? And my answer is always, it's about the community. MediaWiki lends itself so well to community and people enjoy contributing to wikis and wikis. Wikis are just kind of synonymous with community, and they always have been. And Wikipedia sort of set the example when they launched, and it's sort of always been that way. And, you know, I feel like I'm a part of a community when I say a Wiki. And if it was just if it were a custom site that had the ability to contribute to it, you know, it just feels like it's not the same. [01:12:33] Jeremy: I think just even seeing the edit button on Wikis is such a different experience than having the expectation, well, I guess in the case of Leaguepedia, you do have to create an account, but even without creating the account, you can still click edit and you can look at the source and you can see how all this information, or a lot of it, how it got filled in. And I feel like it's kind of more similar to the earlier days of webpages where people could right click a site and click view source and then look at the HTML and the css, and kind of see how it was put together. versus, now with a lot of sites, the, the code has been minified or there's build tools involved so that when you look at view source on websites, it just looks crazy and you're not sure what's going on. So I, I, I feel like wikis in some ways are, kind of closer to the, the spirit of, like the earlier H T M L sites. Yeah. [01:13:46] Megan: And the knowledge transfers too. If you've edit, if you've, if you've ever edited Wikipedia, then you know that like open bracket, open bracket, closed bracket. Closed bracket is how you link a page. and that knowledge transfers to admittedly maybe a little bit less so for Leaguepedia, since there, you need to know how all the templates work and there's not so much direct source editing. it's mostly like clicking the CharInsert prefills. but there's still a lot of cross knowledge transfer, if you've edited one wiki and then change to editing another. And then it goes the other way too. If you edit Leaguepedia, then you want to go at it for the Zelda Wiki, that knowledge will transfer. [01:14:38] Jeremy: And, and talking about the community and the editors. I, I imagine on Wikipedia, most of the people editing are volunteers. Is it the same with Leaguepedia in your experience? [01:14:55] Megan: Um, yeah, so I was contracted, uh, or I was not contracted. My LLC was contract and then I subcontracted. Um, it changed a bit over the years, um, as people left. Uh, so at first I subcontracted quite a few people. Um, and then I guess, as you can imagine, as, there was a lot more data entry that had to be done at the start. And less had to be done later on, as I, expanded the code base so that it was more a single source of truth, and less stuff had to be duplicated. And I guess it was, it probably became a lot more fun too, uh, when you didn't have to edit, enter the same thing multiple times. but, uh, a bunch of people, uh, moved on over the years. and so by the end I was only subcontracting, three people. Um, and everyone else was volunteer. [01:15:55] Jeremy: And and the people that you were subcontracting, that was for only data entry, or was that also for the actual code? [01:16:05] Megan: No, that wasn't for data entry at all. Um, and actually that was for all of my wikis, uh, because I was. Managing like all of the eSports wikis. or on

This week on the show we travel to Switzerland to visit with media conservator Martina Haidvogl. We've heard the conservation program at the Bern Academy of the Arts mentioned a few times on the show so far, as for a long time it was really the only formal conservation training program that had time-based media as a specialization. With time spent in Bern, and as an alum of the Academy of Fine Arts in Vienna, Martina was one of the few first conservators to arrive in the US with formal time-based media conservation training, and now co-directs the Bern Contemporary Art and Media conservation program, so suffice it to say, she's kind a big deal. In our chat we hear about Martina's formative experiences in her early years training as a conservator, the accomplished eight-plus years she spent at SFMOMA's first-ever time-based media art conservator, and the deeply important work she is doing now to train the next generation. We'll also hear about how Martina is thinking through how the conservation profession and the arts ecosystem needs to adapt and evolve to a rapidly changing world around us. Tune in to hear Martina's story!Links from the conversation with Martina> About Team Media at SFMOMA: https://www.sfmoma.org/read/team-media-action-contemplation/> About caring for technology-based artworks and design objects: https://www.sfmoma.org/read/theres-no-app-adventures-conserving-old-tech/> On SFMOMA's MediaWiki documentation platform: https://stedelijkstudies.com/journal/reimagining-the-object-record-sfmomas-mediawiki/> About the HKB's Contemporary Art and Media training program: https://incca.org/training-programme-bern-academy-arts-switzerlandhttps://www.hkb.bfh.ch/en/studies/master/conservation-restoration/> Symposium Contemporary Art Conservation Revisited: 20 years later (program & videos): https://www.hkb.bfh.ch/conscareGet access to exlusive content - join us on Patreon!> https://patreon.com/artobsolescenceJoin the conversation:https://twitter.com/ArtObsolescencehttps://www.instagram.com/artobsolescence/Support artistsArt and Obsolescence is a non-profit podcast, sponsored by the New York Foundation for the Arts, and we are committed to equitably supporting artists that come on the show. Help support our work by making a tax deductible gift through NYFA here: https://www.artandobsolescence.com/donate

Lindsay and Steve talk with Eric Gardner, Senior Software Engineer at the Wikimedia Foundation, about his journey from graphic design to Vue and the adoption of Vue at the Wikimedia Foundation. They discuss the challenges faced in MediaWiki, the core application behind Wikipedia, and how and why the foundation moved to adopt Vue as its frontend framework of choice. They also discuss some of the future developments at the Foundation, as well as some of the challenges that they still face. Panel Lindsay Wardell Steve Edwards Guest Eric Gardner Sponsors Dev Influencers Accelerator Level Up | Devchat.tv PodcastBootcamp.io Links Adopt a modern JavaScript framework for use with MediaWiki Getty Wikimedia Commons Vue.js has been selected as Wikimedia Foundation's future JavaScript framework Abstract Wikipedia Vite Exploring Code Design – VUE 163 Transitioning a Large Front-End Codebase to TypeScript ft. Priscila Oliveira and Mark Story – JSJ 498 Get Started With TypeScript the Easy Way JavaScript Marathon: Upgrade to Typescript with Vue 3 reMARKable - YouTube Wikimedia Phabricator Design Systems Team Twitter: Eric Gardner ( @ecgardner ) Picks Eric- reMARKable Lindsay- GitHub | lindsaykwardell/vite-elm-template Contact Lindsay: Twitter: Lindsay Wardell ( @lindsaykwardell ) Contact Steve: Twitter: Steve Edwards ( @wonder95 ) GitHub: Steve Edwards ( wonder95 ) LinkedIn: Steve Edwards

Lindsay and Steve talk with Eric Gardner, Senior Software Engineer at the Wikimedia Foundation, about his journey from graphic design to Vue and the adoption of Vue at the Wikimedia Foundation. They discuss the challenges faced in MediaWiki, the core application behind Wikipedia, and how and why the foundation moved to adopt Vue as its frontend framework of choice. They also discuss some of the future developments at the Foundation, as well as some of the challenges that they still face. Panel Lindsay Wardell Steve Edwards Guest Eric Gardner Sponsors Dev Influencers Accelerator Level Up | Devchat.tv PodcastBootcamp.io Links Adopt a modern JavaScript framework for use with MediaWiki Getty Wikimedia Commons Vue.js has been selected as Wikimedia Foundation's future JavaScript framework Abstract Wikipedia Vite Exploring Code Design – VUE 163 Transitioning a Large Front-End Codebase to TypeScript ft. Priscila Oliveira and Mark Story – JSJ 498 Get Started With TypeScript the Easy Way JavaScript Marathon: Upgrade to Typescript with Vue 3 reMARKable - YouTube Wikimedia Phabricator Design Systems Team Twitter: Eric Gardner ( @ecgardner ) Picks Eric- reMARKable Lindsay- GitHub | lindsaykwardell/vite-elm-template Contact Lindsay: Twitter: Lindsay Wardell ( @lindsaykwardell ) Contact Steve: Twitter: Steve Edwards ( @wonder95 ) GitHub: Steve Edwards ( wonder95 ) LinkedIn: Steve Edwards

Lindsay and Steve talk with Eric Gardner, Senior Software Engineer at the Wikimedia Foundation, about his journey from graphic design to Vue and the adoption of Vue at the Wikimedia Foundation. They discuss the challenges faced in MediaWiki, the core application behind Wikipedia, and how and why the foundation moved to adopt Vue as its frontend framework of choice. They also discuss some of the future developments at the Foundation, as well as some of the challenges that they still face. Panel Lindsay WardellSteve Edwards Guest Eric Gardner Sponsors Dev Influencers AcceleratorLevel Up | Devchat.tvPodcastBootcamp.io Links Adopt a modern JavaScript framework for use with MediaWikiGettyWikimedia CommonsVue.js has been selected as Wikimedia Foundation's future JavaScript frameworkAbstract WikipediaViteExploring Code Design – VUE 163Transitioning a Large Front-End Codebase to TypeScript ft. Priscila Oliveira and Mark Story – JSJ 498Get Started With TypeScript the Easy WayJavaScript Marathon: Upgrade to Typescript with Vue 3reMARKable - YouTubeWikimedia PhabricatorDesign Systems TeamTwitter: Eric Gardner ( @ecgardner ) Picks Eric- reMARKableLindsay- GitHub | lindsaykwardell/vite-elm-template Contact Lindsay: Twitter: Lindsay Wardell ( @lindsaykwardell ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards Special Guest: Eric Gardner.

Welcome to the PokeGuardian Podcast. This is the 14th episode. The hosts of the show will be Taj from PokéTaj, Zakariya (PrimalLugia), the webmaster of PokeGuardian. And in this episode we have a guest from the United States on our episode: Matthew Verive (immewnity) from Pidgi.net. Immewnity is a mega Pokémon enthusiast and runs primarily Pidgi.net where you can find PidgiWiki. This is a MediaWiki installation created, installed, and run by immewnity and other members. Immewnity also contributes to websites PokeGuardian and PokeGym as part of the staff at both sites and is a Tournament Organizer and Judge. This episode will contain alot of news again, and we will focus on the much anticipated 25th Anniversary sets S8a 25th Anniversary Collection and the English equivalent Celebrations. This set will contain remakes of classic cards such as Base Set Charizard, Gold Star Umbreon and more. Read more on PokeGuardian.com http://www.pokeguardian.com/podcast/698718_pokeguardian-podcast-14-25th-anniversary-collection-celebrations-sets-classic-cards-returning- Timestamps: 00:00 - Intro 01:28- Card Pickups/Highlights 05:25 - 3.7 Billion Pokemon Cards Sold in Fiscal Year 2020-2021 12:20 - Sword & Shield - Evolving Skies Officially Revealed 25:17 - Special Card Set V-UNION Officially Revealed 34:12 - Pokemon Card Game Rubber Playmat Set Sonia Revealed, Sonia TCG Merchandise 39:50 - YU NAGABA x Pokemon Card Game Special BOX and Pikachu Promo Revealed 46:10 - Professor Willow From Pokémon GO Professor's Research Pokémon Card Promo Revealed For All Regions 52:54 - Scorbunny on the Ball GAME UK Exclusive Store Pokémon Futsal Promo Revealed 1:00:17 - 25th Anniversary Set Pokémon TCG: Celebrations & S8a 25th Anniversary Collection Officially Revealed 1:32:15 - Outro

Welcome to the PokeGuardian Podcast. This is the 14th episode. The hosts of the show will be Taj from PokéTaj, Zakariya (PrimalLugia), the webmaster of PokeGuardian. And in this episode we have a guest from the United States on our episode: Matthew Verive (immewnity) from Pidgi.net. Immewnity is a mega Pokémon enthusiast and runs primarily Pidgi.net where you can find PidgiWiki. This is a MediaWiki installation created, installed, and run by immewnity and other members. Immewnity also contributes to websites PokeGuardian and PokeGym as part of the staff at both sites and is a Tournament Organizer and Judge. This episode will contain alot of news again, and we will focus on the much anticipated 25th Anniversary sets S8a 25th Anniversary Collection and the English equivalent Celebrations. This set will contain remakes of classic cards such as Base Set Charizard, Gold Star Umbreon and more. Read more on PokeGuardian.com http://www.pokeguardian.com/podcast/698718_pokeguardian-podcast-14-25th-anniversary-collection-celebrations-sets-classic-cards-returning- Timestamps: 00:00 - Intro 01:28- Card Pickups/Highlights 05:25 - 3.7 Billion Pokemon Cards Sold in Fiscal Year 2020-2021 12:20 - Sword & Shield - Evolving Skies Officially Revealed 25:17 - Special Card Set V-UNION Officially Revealed 34:12 - Pokemon Card Game Rubber Playmat Set Sonia Revealed, Sonia TCG Merchandise 39:50 - YU NAGABA x Pokemon Card Game Special BOX and Pikachu Promo Revealed 46:10 - Professor Willow From Pokémon GO Professor's Research Pokémon Card Promo Revealed For All Regions 52:54 - Scorbunny on the Ball GAME UK Exclusive Store Pokémon Futsal Promo Revealed 1:00:17 - 25th Anniversary Set Pokémon TCG: Celebrations & S8a 25th Anniversary Collection Officially Revealed 1:32:15 - Outro

Welcome to the History of Computing Podcast, where we explore the history of information technology. Because understanding the past prepares us for the innovations of the future! Todays episode is on the history of Wikipedia. The very idea of a single location that could store all the known information in the world began with Ptolemy I, founder of the Greek dynasty that ruled Egypt following the death of Alexander the great. He and his son amassed 100s of thousands of scrolls in the Library and Alexandria from 331 BC and on. The Library was part of a great campus of the Musaeum where they also supported great minds starting with Ptolemy I's patronage of Euclid, the father of geometry, and later including Archimedes, the father of engineering, Hipparchus, the founder of trigonometry, Her, the father of math, and Herophilus, who gave us the scientific method and countless other great hellenistic thinkers. The Library entered into a slow decline that began with the expulsion of intellectuals from Alexandria in 145BC. Ptolemy VIII was responsible for that. Always be weary of people who attack those that they can't win over especially when they start blaming the intellectual elite for the problems of the world. This began a slow decline of the library until it burned, first with a small fire accidentally set by Caesar in 48BC and then for good in the 270s AD. In the centuries since there have been attempts here and there to gather great amounts of information. The first known encyclopedia was the Naturalis Historiae by Pliny the Elder, never completed because he was killed in the eruption of Vesuvius. One of the better known being the Encyclopedia Britannica, starting off in 1768. Mass production of these was aided by the printing press but given that there's a cost to producing those materials and a margin to be made in the sale of those materials that encouraged a somewhat succinct exploration of certain topics. The advent of the computer era of course led to encyclopedias on CD and then to online encyclopedias. Encyclopedias at the time employed experts in certain fields and paid them for compiling and editing articles for volumes that would then be sold. As we say these days, this was a business model just waiting to be disrupted. Jimmy Wales was moderating an online discussion board on Objectivism and happened across Larry Sanger in the early 90s. They debated and became friends. Wales started Nupedia, which was supposed to be a free encyclopedia, funded by advertising revenue. As it was to be free, they were to recruit thousands of volunteer editors. People of the caliber that had been previously hired to research and write articles for encyclopedias. Sanger, who was pursuing a PhD in philosophy from Ohio State University, was hired on as editor-in-chief. This was a twist on the old model of compiling an encyclopedia and a twist that didn't work out as intended. Volunteers were slow to sign up, but Nupedia went online in 2000. Later in the year there had only been two articles that made it through the review process. When Sanger told Ben Kovitz about this, he recommended looking at the emerging wiki culture. This had been started with WikiWikiWeb, developed by Ward Cunningham in 1994, named after a shuttle bus that ran between airport terminals at the Honolulu airport. WikiWikiWeb had been inspired by Hypercard but needed to be multi-user so people could collaborate on web pages, quickly producing content on new patterns in programming. He wanted to make non-writers feel ok about writing. Sanger proposed using a wiki to be able to accept submissions for articles and edits from anyone but still having a complicated review process to accept changes. The reviewers weren't into that, so they started a side project they called Wikipedia in 2001 with a user-generated model for content, or article, generation. The plan was to generate articles on Wikipedia and then move or copy them into Nupedia once they were ready. But Wikipedia got mentioned on Slashdot. In 2001 there were nearly 30 million websites but half a billion people using the web. Back then a mention on the influential Slashdot could make a site. And it certainly helped. They grew and more and more people started to contribute. They hit 1,000 articles in March of 2001 and that increased by 10 fold by September, By And another 4 fold the next year. It started working independent of Nupedia. The dot-com bubble burst in 2000 and by 2002 Nupedia had to lay Sanger off and he left both projects. Nupedia slowly died and was finally shut down in 2003. Eventually the Wikimedia Foundation was built to help unlock the world's knowledge, which now owns and operates Wikipedia. Wikimedia also includes Commons for media, Wikibooks that includes free textbooks and manuals, Wikiquote for quotations, Wikiversity for free learning materials, MediaWiki the source code for the site, Wikidata for pulling large amounts of data from Wikimedia properties using APIs, Wikisource, a library of free content, Wikivoyage, a free travel guide, Wikinews, free news, Wikispecies, a directory containing over 687,000 species. Many of the properties have very specific ways of organizing data, making it easier to work with en masse. The properties have grown because people like to be helpful and Wales allowed self-governance of articles. To this day he rarely gets involved in the day-to-day affairs of the wikipedia site, other than the occasional puppy dog looks in banners asking for donations. You should donate. He does have 8 principles the site is run by: 1. Wikipedia's success to date is entirely a function of our open community. 2. Newcomers are always to be welcomed. 3. “You can edit this page right now” is a core guiding check on everything that we do. 4. Any changes to the software must be gradual and reversible. 5. The open and viral nature of the GNU Free Documentation License and the Create Commons Attribution/Share-Alike License is fundamental to the long-term success of the site. 6. Wikipedia is an encyclopedia. 7. Anyone with a complaint should be treated with the utmost respect and dignity. 8. Diplomacy consists of combining honesty and politeness. This culminates in 5 pillars wikipedia is built on: 1. Wikipedia is an encyclopedia. 2. Wikipedia is written from a neutral point of view. 3. Wikipedia is free content that anyone can use, edit, and distribute. 4. Wikipedia's editors should treat each other with respect and civility. 5. Wikipedia has no firm rules. Sanger went on to found Citizendium, which uses real names instead of handles, thinking maybe people will contribute better content if their name is attached to something. The web is global. Throughout history there have been encyclopedias produced around the world, with the Four Great Books of Song coming out of 11th century China, the Encyclopedia of the Brethren of Purity coming out of 10th century Persia. When Wikipedia launched, it was in English. Wikipedia launched a German version using the deutsche.wikipedia.com subdomain. It now lives at de.wikipedia.com and Wikipedia has gone from being 90% English to being almost 90 % non-English, meaning that Wikipedia is able to pull in even more of the world's knowledge. Wikipedia picked up nearly 20,000 English articles in 2001, over 75,000 new articles in 2002, and that number has steadily climbed wreaching over 3,000,000 by 2010, and we're closing in on 6 Million today. The English version is 10 terabytes of data uncompressed. If you wanted to buy a printed copy of wikipedia today, it would be over 2500 books. By 2009 Microsoft Encarta shut down. By 2010 Encyclopedia Britannica stopped printing their massive set of books and went online. You can still buy encyclopedias from specialty makers, such as the World Book. Ironically, Encyclopedia Britannica does now put real names of people on articles they produce on their website, in an ad-driven model. There are a lot of ads. And the content isn't linked to as many places nor as thorough. Creating a single location that could store all the known information in the world seems like a pretty daunting task. Compiling the non-copywritten works of the world is now the mission of Wikipedia. The site receives the fifth most views per month and is read by nearly half a billion people a month with over 15 billion page views per month. Anyone who has gone down the rabbit hole of learning about Ptolemy I's involvement in developing the Library of Alexandria and then read up on his children and how his dynasty lasted until Cleopatra and how… well, you get the point… can understand how they get so much traffic. Today there are over 48,000,000 articles and over 37,000,000 registered users who have contributed articles meaning if we set 160 Great Libraries of Alexandria side-by-side we would have about the same amount of information Wikipedia has amassed. And it's done so because of the contributions of so many dedicated people. People who spend hours researching and building pages, undergoing the need to provide references to cite the data in the articles (btw wikipedia is not supposed to represent original research), more people to patrol and look for content contributed by people on a soapbox or with an agenda, rather than just reporting the facts. Another team looking for articles that need more information. And they do these things for free. While you can occasionally see frustrations from contributors, it is truly one of the best things humanity has done. This allows us to rediscover our own history, effectively compiling all the facts that make up the world we live in, often linked to the opinions that shape them in the reference materials, which include the over 200 million works housed at the US Library of Congress, and over 25 million books scanned into Google Books (out of about 130 million). As with the Great Library of Alexandria, we do have to keep those who seek to throw out the intellectuals of the world away and keep the great works being compiled from falling to waste due to inactivity. Wikipedia keeps a history of pages, to avoid revisionist history. The servers need to be maintained, but the database can be downloaded and is routinely downloaded by plenty of people. I think the idea of providing an encyclopedia for free that was sponsored by ads was sound. Pivoting the business model to make it open was revolutionary. With the availability of the data for machine learning and the ability to enrich it with other sources like genealogical research, actual books, maps, scientific data, and anything else you can manage, I suspect we'll see contributions we haven't even begun to think about! And thanks to all of this, we now have a real compendium of the worlds knowledge, getting more and more accurate and holistic by the day. Thank you to everyone involved, from Jimbo and Larry, to the moderators, to the staff, and of course to the millions of people who contribute pages about all the history that makes up the world as we know it today. And thanks to you for listening to yet another episode of the History of Computing Podcast. We're lucky to have you. Have a great day! Note: This work was produced in large part due to the compilation of historical facts available at https://en.wikipedia.org/wiki/History_of_Wikipedia

Xavier LeroyCollège de FranceScience du logicielAnnée 2018-2019Leçon inaugurale : Le logiciel, entre l'esprit et la matière.Les travaux de recherche de Xavier LEROY portent d'une part sur les nouveaux langages et outils de programmation, et d'autre part sur la vérification formelle de logiciels critiques afin de garantir leur sûreté et leur sécurité. Il est l'architecte et l'un des principaux développeurs du langage de programmation fonctionnelle OCaml ainsi que du compilateur C formellement vérifié CompCert, deux grands logiciels issus de la recherche.Langages fonctionnels, systèmes de types et mise en pratique : les langages Caml Light et OCamlXavier LEROY a été formé aux mathématiques et à l'informatique à l'École normale supérieure, puis à l'INRIA où il a effectué sa thèse. Programmeur prodige, il s'est illustré par une série de travaux de premier plan sur les systèmes de types et les systèmes de modules pour les langages fonctionnels, qui ont abouti au développement de Caml Light, devenu aujourd'hui OCaml, l'un des deux langages fonctionnels typés les plus utilisés au monde, dans des domaines aussi divers que l'aéronautique, la finance ou encore le Web. Ce langage est le support de développement d'outils logiciels très variés comme l'assistant de preuve Coq, les analyseurs statiques Astrée et Frama-C, le compilateur SCADE 6 d'Estérel Technologies et la blockchain Tezos. OCaml a été utilisé dans de nombreux projets emblématiques comme la version web de Facebook Messenger, le logiciel MediaWiki ou encore l'infrastructure de virtualisation Docker.Preuve de programme, preuve de compilateurs et mise en pratique : le compilateur CompCert Xavier LEROY est également à l'origine de CompCert, qui est un compilateur C certifié, écrit et vérifié grâce à l'assistant de preuve Coq. Il s'agit d'une première mondiale à plusieurs titres : il autorise une vérification formelle d'une taille et d'une complexité sans précédent, et surtout, il offre la possibilité de disposer d'un compilateur certifié, étape clé dans la certification et la vérification automatique des chaînes logicielles, et donc vers la programmation « zéro défaut ». Ce fait d'arme a eu un impact considérable sur la nature même des grands programmes de recherche sur les logiciels. Nommé professeur au Collège de France, Xavier LEROY occupera la chaire Sciences du logiciel où il dispensera dès l'année académique 2018-2019 une série de cours intitulée Programmer = démontrer ? La correspondance de Curry-Howard aujourd'hui.Leçon inaugurale jeudi 15 novembre 2018 à 18h00

Xavier LeroyCollège de FranceScience du logicielAnnée 2018-2019Leçon inaugurale : Le logiciel, entre l'esprit et la matière.Les travaux de recherche de Xavier LEROY portent d'une part sur les nouveaux langages et outils de programmation, et d'autre part sur la vérification formelle de logiciels critiques afin de garantir leur sûreté et leur sécurité. Il est l'architecte et l'un des principaux développeurs du langage de programmation fonctionnelle OCaml ainsi que du compilateur C formellement vérifié CompCert, deux grands logiciels issus de la recherche.Langages fonctionnels, systèmes de types et mise en pratique : les langages Caml Light et OCamlXavier LEROY a été formé aux mathématiques et à l'informatique à l'École normale supérieure, puis à l'INRIA où il a effectué sa thèse. Programmeur prodige, il s'est illustré par une série de travaux de premier plan sur les systèmes de types et les systèmes de modules pour les langages fonctionnels, qui ont abouti au développement de Caml Light, devenu aujourd'hui OCaml, l'un des deux langages fonctionnels typés les plus utilisés au monde, dans des domaines aussi divers que l'aéronautique, la finance ou encore le Web. Ce langage est le support de développement d'outils logiciels très variés comme l'assistant de preuve Coq, les analyseurs statiques Astrée et Frama-C, le compilateur SCADE 6 d'Estérel Technologies et la blockchain Tezos. OCaml a été utilisé dans de nombreux projets emblématiques comme la version web de Facebook Messenger, le logiciel MediaWiki ou encore l'infrastructure de virtualisation Docker.Preuve de programme, preuve de compilateurs et mise en pratique : le compilateur CompCert Xavier LEROY est également à l'origine de CompCert, qui est un compilateur C certifié, écrit et vérifié grâce à l'assistant de preuve Coq. Il s'agit d'une première mondiale à plusieurs titres : il autorise une vérification formelle d'une taille et d'une complexité sans précédent, et surtout, il offre la possibilité de disposer d'un compilateur certifié, étape clé dans la certification et la vérification automatique des chaînes logicielles, et donc vers la programmation « zéro défaut ». Ce fait d'arme a eu un impact considérable sur la nature même des grands programmes de recherche sur les logiciels. Nommé professeur au Collège de France, Xavier LEROY occupera la chaire Sciences du logiciel où il dispensera dès l'année académique 2018-2019 une série de cours intitulée Programmer = démontrer ? La correspondance de Curry-Howard aujourd'hui.Leçon inaugurale jeudi 15 novembre 2018 à 18h00

Xavier Leroy Collège de France Science du logiciel Année 2018-2019 Leçon inaugurale : Le logiciel, entre l'esprit et la matière. Les travaux de recherche de Xavier LEROY portent d'une part sur les nouveaux langages et outils de programmation, et d'autre part sur la vérification formelle de logiciels critiques afin de garantir leur sûreté et leur sécurité. Il est l'architecte et l'un des principaux développeurs du langage de programmation fonctionnelle OCaml ainsi que du compilateur C formellement vérifié CompCert, deux grands logiciels issus de la recherche. Langages fonctionnels, systèmes de types et mise en pratique : les langages Caml Light et OCaml Xavier LEROY a été formé aux mathématiques et à l'informatique à l'École normale supérieure, puis à l'INRIA où il a effectué sa thèse. Programmeur prodige, il s'est illustré par une série de travaux de premier plan sur les systèmes de types et les systèmes de modules pour les langages fonctionnels, qui ont abouti au développement de Caml Light, devenu aujourd'hui OCaml, l'un des deux langages fonctionnels typés les plus utilisés au monde, dans des domaines aussi divers que l'aéronautique, la finance ou encore le Web. Ce langage est le support de développement d'outils logiciels très variés comme l'assistant de preuve Coq, les analyseurs statiques Astrée et Frama-C, le compilateur SCADE 6 d'Estérel Technologies et la blockchain Tezos. OCaml a été utilisé dans de nombreux projets emblématiques comme la version web de Facebook Messenger, le logiciel MediaWiki ou encore l'infrastructure de virtualisation Docker. Preuve de programme, preuve de compilateurs et mise en pratique : le compilateur CompCert Xavier LEROY est également à l'origine de CompCert, qui est un compilateur C certifié, écrit et vérifié grâce à l'assistant de preuve Coq. Il s'agit d'une première mondiale à plusieurs titres : il autorise une vérification formelle d'une taille et d'une complexité sans précédent, et surtout, il offre la possibilité de disposer d'un compilateur certifié, étape clé dans la certification et la vérification automatique des chaînes logicielles, et donc vers la programmation « zéro défaut ». Ce fait d'arme a eu un impact considérable sur la nature même des grands programmes de recherche sur les logiciels. Nommé professeur au Collège de France, Xavier LEROY occupera la chaire Sciences du logiciel où il dispensera dès l'année académique 2018-2019 une série de cours intitulée Programmer = démontrer ? La correspondance de Curry-Howard aujourd'hui. Leçon inaugurale jeudi 15 novembre 2018 à 18h00

Xavier Leroy Collège de France Science du logiciel Année 2018-2019 Leçon inaugurale : Le logiciel, entre l'esprit et la matière. Les travaux de recherche de Xavier LEROY portent d'une part sur les nouveaux langages et outils de programmation, et d'autre part sur la vérification formelle de logiciels critiques afin de garantir leur sûreté et leur sécurité. Il est l'architecte et l'un des principaux développeurs du langage de programmation fonctionnelle OCaml ainsi que du compilateur C formellement vérifié CompCert, deux grands logiciels issus de la recherche. Langages fonctionnels, systèmes de types et mise en pratique : les langages Caml Light et OCaml Xavier LEROY a été formé aux mathématiques et à l'informatique à l'École normale supérieure, puis à l'INRIA où il a effectué sa thèse. Programmeur prodige, il s'est illustré par une série de travaux de premier plan sur les systèmes de types et les systèmes de modules pour les langages fonctionnels, qui ont abouti au développement de Caml Light, devenu aujourd'hui OCaml, l'un des deux langages fonctionnels typés les plus utilisés au monde, dans des domaines aussi divers que l'aéronautique, la finance ou encore le Web. Ce langage est le support de développement d'outils logiciels très variés comme l'assistant de preuve Coq, les analyseurs statiques Astrée et Frama-C, le compilateur SCADE 6 d'Estérel Technologies et la blockchain Tezos. OCaml a été utilisé dans de nombreux projets emblématiques comme la version web de Facebook Messenger, le logiciel MediaWiki ou encore l'infrastructure de virtualisation Docker. Preuve de programme, preuve de compilateurs et mise en pratique : le compilateur CompCert Xavier LEROY est également à l'origine de CompCert, qui est un compilateur C certifié, écrit et vérifié grâce à l'assistant de preuve Coq. Il s'agit d'une première mondiale à plusieurs titres : il autorise une vérification formelle d'une taille et d'une complexité sans précédent, et surtout, il offre la possibilité de disposer d'un compilateur certifié, étape clé dans la certification et la vérification automatique des chaînes logicielles, et donc vers la programmation « zéro défaut ». Ce fait d'arme a eu un impact considérable sur la nature même des grands programmes de recherche sur les logiciels. Nommé professeur au Collège de France, Xavier LEROY occupera la chaire Sciences du logiciel où il dispensera dès l'année académique 2018-2019 une série de cours intitulée Programmer = démontrer ? La correspondance de Curry-Howard aujourd'hui. Leçon inaugurale jeudi 15 novembre 2018 à 18h00

Xavier Leroy Collège de France Science du logiciel Année 2018-2019 Leçon inaugurale : Le logiciel, entre l'esprit et la matière. Les travaux de recherche de Xavier LEROY portent d'une part sur les nouveaux langages et outils de programmation, et d'autre part sur la vérification formelle de logiciels critiques afin de garantir leur sûreté et leur sécurité. Il est l'architecte et l'un des principaux développeurs du langage de programmation fonctionnelle OCaml ainsi que du compilateur C formellement vérifié CompCert, deux grands logiciels issus de la recherche. Langages fonctionnels, systèmes de types et mise en pratique : les langages Caml Light et OCaml Xavier LEROY a été formé aux mathématiques et à l'informatique à l'École normale supérieure, puis à l'INRIA où il a effectué sa thèse. Programmeur prodige, il s'est illustré par une série de travaux de premier plan sur les systèmes de types et les systèmes de modules pour les langages fonctionnels, qui ont abouti au développement de Caml Light, devenu aujourd'hui OCaml, l'un des deux langages fonctionnels typés les plus utilisés au monde, dans des domaines aussi divers que l'aéronautique, la finance ou encore le Web. Ce langage est le support de développement d'outils logiciels très variés comme l'assistant de preuve Coq, les analyseurs statiques Astrée et Frama-C, le compilateur SCADE 6 d'Estérel Technologies et la blockchain Tezos. OCaml a été utilisé dans de nombreux projets emblématiques comme la version web de Facebook Messenger, le logiciel MediaWiki ou encore l'infrastructure de virtualisation Docker. Preuve de programme, preuve de compilateurs et mise en pratique : le compilateur CompCert Xavier LEROY est également à l'origine de CompCert, qui est un compilateur C certifié, écrit et vérifié grâce à l'assistant de preuve Coq. Il s'agit d'une première mondiale à plusieurs titres : il autorise une vérification formelle d'une taille et d'une complexité sans précédent, et surtout, il offre la possibilité de disposer d'un compilateur certifié, étape clé dans la certification et la vérification automatique des chaînes logicielles, et donc vers la programmation « zéro défaut ». Ce fait d'arme a eu un impact considérable sur la nature même des grands programmes de recherche sur les logiciels. Nommé professeur au Collège de France, Xavier LEROY occupera la chaire Sciences du logiciel où il dispensera dès l'année académique 2018-2019 une série de cours intitulée Programmer = démontrer ? La correspondance de Curry-Howard aujourd'hui. Leçon inaugurale jeudi 15 novembre 2018 à 18h00

Audrey Eschright: @ameschright | The Recompiler Show Notes: 00:50 - Background in Publishing and Open Source 06:53 - The Contributor Pool 12:37 - Open Source Bridge 15:29 - Mistakes Open Source Contributors Make 17:21 - Tools for Maintaining an Open Source Project 19:09 - Roles 23:33 - Open Source Bridge (Cont'd) 27:47 - Governance and Decision-Making 36:20 - Making Open Source Accessible, Safe, and Welcoming Resources: Free Geek Calagator PDX Activist Dreamwidth Safety First PDX Open Source Bridge: Enter the coupon code PODCAST to get $50 off a ticket! The conference will be held June 20-23, 2017 at The Eliot Center in downtown Portland, Oregon. Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode #71. My name is Charles Lowell. I'm a developer here at The Frontside. With me also is Joe LaSala. JOE: Hello. CHARLES: Hey, Joe, another developer here at The Frontside. With us today is the publisher of The Recompiler Mag and a long-time open source contributor Audrey Eschright. Welcome Audrey. AUDREY: Hey! CHARLES: Thanks for being on the show. AUDREY: Oh, thank you. CHARLES: Today, we're going to be talking about open source and in particular, the labor that goes into open source and making that sustainable but before we get into that, I wanted to first talk about your background, both in terms of how you came to be publishing the magazine and also your background on open source, how we're arriving at the subject today. AUDREY: The magazine, in a lot of ways, I refer to it as a feminist hacker magazine. It holds together a lot of different things that I've worked on over the years so I'm going to jump all the way back to when I first encountered open source and then maybe that will fit together. When I was in high school, I first encountered the internet and the internet that was available to me at that time use things like Gopher. Gopher is a pretty web protocol and it was free software. I didn't really understand that it was free software at that point but I did understand that if I wanted to learn how to write code and the computer that I have access to were things like a bunch of really old PCs like 286's and an old Macintosh. Then there were commercial compilers for writing code and there were free compilers for writing code. There was a thing called GCC and I knew that it was on university computers and if I got access to those, then I could write code. Then I got to college and write about when open source really started to take off as this concept of how free software comes into business world. I've had that as a background of becoming a programmer and getting involved in things but after college I wasn't really sure that I want to work in technology so I took a break. When I came back, I needed a way to get myself up to date so I started volunteering with this local group called Free Geek that recycles computers. What they do is they take those computer parts and the ones that are usable, they build them into Linux boxes for people, like Linux desktop boxes. How I got back up and running was learning how to work and volunteering in an organization that was very open source based, like all of the tools that they used are just completely open source. CHARLES: Was that for budgetary reasons or they didn't want the people to burden the recipients of these computers with any licensing fees or obligations to third parties? AUDREY: It's budgetary but it's also ideological. The organization was started out of environmental interests. The original folks, they pointed to us this computer monitor that they [inaudible] as the reason that they do this, that the way computer waste is being handled was so unfriendly that you might as well just dump it in the river. They started from there but I think because those kinds of interests of creating something that was really accessible for people are really educational and accessible to lower income patrons has always been a really big part of it. I think that using Linux and using open source tools has been a big part of that. CHARLES: I think open source is so pervasive, a lot of people forget that in those days, there was a lot of radical thinking behind it, of radical accessibility like it's your basic right to be able to access every layer of your stack. It's a little bit unfortunate that you mentioned GCC that like the GNU, the Free Software Foundation isn't as much part of the conversation as they were back then. AUDREY: Yeah. I think that as more people come in to, we've shifted through these different generations basically in open source contribution and how it's formulated. The fact that I even default to open source is really interesting because a lot of the values that I referencing are those free software values. CHARLES: Fast forward to the present... AUDREY: Part of how I built my skills was by starting open source projects called Calagator. It's a community calendaring platform that makes it very easy to import things from other sources like Facebook. It's interesting, it wasn't our primary thing but it's so big now. We've been doing this for 10 years so a lot of recent change around us. We have a 10-year old [inaudible] app that is still up and running and is now in Rails engine. CHARLES: Wow. Is this an application that you can run yourself or when you say it's an engine, if I've got a Rails app, I can just drop it into any Rails app? AUDREY: Yeah, that was a direction we decided to go in a couple of years ago because my experience was that handing people in Rails app and saying, "Go fork it and then go sell it and use it in your community." That's a pretty big technical burden. At least, as an engine, it makes it a little bit more flexible for people to really come in and make some of those changes. We can bootstrap a little bit more for them. CHARLES: It's always funny to me know how some projects always run off the fork model, like there's a lot of HTML starters or editor starters where the thing is you fork it. I always hate that model because eventually, you ended up having to do this terrible dance with the upstream in order to jump around the changes that are coming through and stuff. AUDREY: Yeah and that was definitely one of the problems that we would run into. We would make changes to functionality and the frontend and the visual display of it. It was really difficult for people to pick and choose the parts that were useful for them. CHARLES: Yeah. Okay, so you've got a 10-year old Rails applications/engine, now you are actually running an instance of this engine yourself or just maintaining the open source? AUDREY: Yeah, there's actually two of them, that I'm in involved with right now. One of them is that Calagator.org. It's a Portland's techs events calendar. That was really our original site and the reason that we created this. The other one just as of a few months ago is PDXActivist.org and that is a way to get a lot of activism and political organizing off of Facebook, basically. That's really our primary target. It's just getting people an alternative to using Facebook for all of their events. CHARLES: I see. Now, having to maintain an open source project for 10 years, that's a really, really long time. AUDREY: Yeah. CHARLES: How big is the community now and how many different users have you seen as you developed this? AUDREY: Well, it's a little hard to tell. We deliberately don't do a lot of tracking, especially on PDX Activist side. I can tell you that there are a lot of events on both calendars. For the tech events, there are probably five things that you can do on any given day, maybe 10. During design week, they put all that on there too. This has been very consistent over the history of the project. I can also tell you that we've had dozens of contributors. CHARLES: Yeah, that's more what I meant when I said users. Not necessarily the consumers of the calendar but the consumers of the software that makes the calendar. AUDREY: It goes without saying that I think that those users are creating events, they are part of that because they help curate content. Like with the wiki, your user base isn't just the people who update MediaWiki. It's that people who really work on the content too. We've had dozens of people. There's a contributor's file that I didn't pull up but we can go and look at it. We made a point of crediting everybody who contributed at Code Sprint, whether or not they check in code. We have a really great documentation over the history of the project about how the different ways that people contributed and who they are. CHARLES: Yeah. I feel like that's something that often goes missing in projects, especially open source projects that you find on GitHub where there's so many people that are involved in creating software beyond just what you see in the commit history. It's kind of a poor showing of what it was all involved in the whole creative act. Sure, it's an accurate reflection if it's a one-person project who's hacking away on weekends but as your project scales, there's a lot of different stuff going on. AUDREY: Yeah, definitely. I think the other part that's really interesting for me about this is that I can point to that big contributor pool, people who have come to sprints so they've work on a project. They help define the shape of the project. Then I can tell you that we had a three-person core team for a very long time and then it was down to a two-person core team. Now, I'm not really sure which one of those is in charge. I don't look at GitHub often enough and a couple of the other computers. There isn't a lot of coaching happening anymore. We should have a wish list but there's nothing so urgent that we stop all other work and go back to making this our primary effort. CHARLES: Of the people on the core team, how many of them are developers? AUDREY: All of us. All three of us were. We come into with different cross skills. I've done a lot of documentation and mentorship. As of the others, I would say we have one person who were in design or one person who was more apps-oriented. We fill those different layers too. CHARLES: Of that group of the core contributors, outside that group of core contributors, you said you accumulate a list of all the people who contributed. What's the breakdown in the roles that those people are playing? AUDREY: You know, it has changed a lot over the course of the project. Early on, we had maybe half of the people were really doing development and the other half were helping. We took a very agile approach like index cards and users story. Maybe half of the people that show up at a given time, we just talk through the feature and do research. We were looking at a lot of integration so what needed to know what would be required to integrate it. We brainstorm a lot of things. We did in-person Code Sprints every two weeks from the year that we started, at late of January to the end of July. We had this whole set of in-person work that really shape in that. Also a lot of people who weren't necessarily contributing code that had disappeared. CHARLES: I see, so people who had a vested interest in a particular set of features could show up and voice that interest and be heard, as opposed to what you're having, it just be limited to the people who are writing the actual code. AUDREY: Yeah and we would ask people to spec it out. Just sit down with somebody and figure out how the feature could work and whether it fit with everything else to what we're doing. I do that research and investigation. Over the years, we've had this come and go in waves. Every so often, we need to go up a Rails version or make certain kinds of major updates so we get people together for that. We had some different pools of Codeschool students that have come in and really been interested in working on this to get a little bit more development experience, get some experience working with other people, have open source some resume to show off. I've been very enthusiastic about giving people that resume credit that if they need an open source of it so that they could say, "I know how to write with other people," then our projects is very happy to help them with that. CHARLES: What is the conference that you run? AUDREY: I am on the committee for Open Source Bridge. It's an annual conference for open source citizens, which is the same people who participate and benefit from open source. CHARLES: Which is pretty much the planet at this point. AUDREY: Yeah. It's funny because, I think it's just so interesting who does or doesn't identify themselves as part of that. Anybody using a computer these days is in some way benefiting from open source and could potentially contribute to it and be part of that. It's not just awareness, there are a lot of actual barriers so that, to everyone having a role in it. But the conference I co-founded it with Selena Deckelmann who's at Mozilla now. We do say over time to ask a lot of questions about how across technologies, open source comes together to build things? How projects work? What kinds of skills are involved? How we become better maintainers by being aware of our users, by communicating better, by being good moderators of online message boards and mailing lists and things like that? We've had a chance to really just look at broad swath of elements that come in. CHARLES: I think that literally every bullet point that you mentioned, I feel is something that we've come across and it has been a challenge for us, in our efforts to maintain our open source projects. Ours are mostly just libraries. There's very little by way of big, big frameworks or big, big applications. We've got it kind of easy, I would say and we still struggle with those things really understanding our users, understanding how your open source project should run and how it even fits into the bigger ecosystem. Is there a guide out there somewhere like how to how to open source? AUDREY: You know, I don't know that I've seen a single guide but there is really a lot of good writing and a lot of good conference talks on this topics. Like you said, it's just this broad set of skills and we focus so much on teaching people how to code and maybe teaching people how to code together, to be good contributors together but if you ever to maintain a project, there's leadership involved. There's communication involved. CHARLES: It seems to me that's the bulk of it, right? AUDREY: Yeah. I don't know, did you get training on that? [Laughter] AUDREY: I just decided to try things. I'm very lucky that I'm mostly made good guesses but there's some really bad ones too where later I look back at it and realized we could have done better. CHARLES: What are some of this mistakes that open source contributors often make, where they could save themselves a lot of trouble? AUDREY: I think a big one is thinking about it only in that technical framework. Even just by tools that we use, we tend to force people into contributing solely through GitHub, which means that you've got to understand somethings about the bug tracker and how tickets go and the workflow around that. CHARLES: Yeah. I've literally looking at a message in our Slack from yesterday where someone on our team who doesn't interact with GitHub said literally, "Someone is going to have to show me how because GitHub is the most confusing thing I have ever logged into." JOE: I thought about that message today too and yeah, I guess I'm wondering how do you attract those more non-technical skill sets to a project? AUDREY: It takes a lot of direct mentoring and coaching. You already has some people that are identifying themselves to you if you're having that conversation. I think I've really benefited from looking at who else is like them, who else do they know that might want to get involved and starting conversations that way. Because the biggest projects that I have worked on are these calendars, it does give us so many users that maybe are interested in having more technical involvement. If I can start looking at who's doing a lot of cleanup on there, who's paying a lot of attention to the content and the structure of the content and structuring information is also a technical skill. But people don't necessarily go from that to thinking, "I can write code," or, "I could submit a ticket and debug that thing and tell you what needs fixing now." But people can get there. We just have to be willing to talk to them about it and willing to look at it from their point of view. CHARLES: One thing that I dig out of there is that if you're running your open source project solely on GitHub, it's not going to be enough. You're going to be constrained in your growth just by the toolset and the implicit exclusivity of that toolset. What are some tools that you can bring in that are going to be more attractive? AUDREY: I think mailing list have turnout to be one of the most open-ended things that we've done. People who want to find out a little bit more, sometimes post there but also just having a good webpage, a good info pages or some sort, having your wiki actually talked about some of the less technical aspects of it. Even explaining what your project is for can be really good. You know, you start to make these assumptions like, "If they're going to go and install it, do they know?" Maybe not. I think just looking at it as a broader set of communications. CHARLES: Right. What seems self-evident to you and maybe someone who shares a lot of context to you is a mystery to someone else. It never hurts to state the obvious. It seems to me you have to be able to use tools that people are familiar with but also part of the leadership is giving people things to do, giving them a way to think about your project or giving them a way to act independently. How do you think about the different roles in an open source project so that you can then elucidate those roles so that someone coming, who is going to look at your website or who's going to be reading your e-mail list is going to be participating in your community in some way and particularly not in a code contribution way, how do you think about the different roles of your open source project so that you can kind of hand that to them? So that they can act independently like, "Here's this thing that you could do. Here's this thing that you could do. Here's this thing that you can do." What is that kind of core set of roles? CHARLES: We could think about it in terms of the actions that we take. If you go back to our lone weekend coder who put something on GitHub, you're already writing the code, making design decisions about the shape of the code, you are writing about it in some way, even if all you do is update the ReadMe to have two lines of something you're writing. You are managing any bug tickets that come in, any future request so you're doing some project management, some kind of general analysis of that. They don't necessarily have to be different roles. People implicitly take on the whole thought of that when they start a project. But they can also be split out. I hate to say like, "Give away your least favorite thing," because people sometimes do that, may dump it out there and it never gets handled well because they don't really understand what they're looking for. But it's okay to say, "I am really great at this one thing and I really struggle with this other thing." I bet there's somebody else who is just way better at organizing the stack communication and they can help me with that. If I can tell them what I need it for, maybe they can help with that. CHARLES: So you have to admit your weaknesses? AUDREY: Yeah. I think a lot of leadership is that kind of self-analysis: really seeing where you are helping the most, where you're strongest, what things absolutely have to be done with you. I don't know. I'd learned you to be really honest about that. Sometimes, the thing you enjoy doing is not the thing that you have to do because nobody else can. But often barred things that are really not fun for me, turned out to be the thing that nobody else can do. I just think that you have to spent some time thinking about that and thinking about what you can teach people too. You already have the knowledge of your project and what you're trying to do so I think what you can teach is what your mission is, what your goals are and maybe they can help you to communicate that too. CHARLES: Yeah, because it seems to me if you actually can very clearly communicate your target, then people can begin to walk towards it independently and that's almost more important than the actual taking the steps. Or the steps needed to be taken but that's something that you can provide. AUDREY: Yeah, you need that kind of definition regardless in order to make your decision and have your work actually function and the less conscious we are about, the more we tend to get a big pile of something and you go, "Now what? What do we do with that?" CHARLES: Right. I think it also flushes out if you have a clear target and you have a clear mission, by externalizing it, it makes you reflect on it more and hardens it, if that makes any sense. You have all these ideas bouncing around in your own head about the things that you might want to do or might like to do but once you actually try to express it to people and say, "You know what? We're going to do this." Then it takes on a reality of its own that is subject to more scrutiny but also subject to the constraints of the real world and that's a good thing. It means that whatever you're going to come up with is going to be more resilient. AUDREY: Yeah. I think we can be scared about putting that out there. They won't see what you see or they won't like it. Those who disagree with your goals there will go, "You really should have been building an eggplant slicer and not a tomato slicer." Yeah, I don't like tomatoes. But for more definition that we put out there, the clearer we are, the more that the people who want to [inaudible] they can find us. That's why it's so important to do it and not to dodge those kinds of questions. CHARLES: Yeah, absolutely. Now, I'm wondering so when is this conference that you're running? Is this the first one or is this the second, the third? AUDREY: Oh, no. We're on our ninth. CHARLES: You are on your ninth? Oh, my goodness. AUDREY: Yeah, it's actually just in a few weeks. It's in June, the week of the 20th, I want to say. Tickets are for sale. If you're in Portland, we had a great volunteer program where you put in eight hours over the course of the entire week. You can split out with everyone and you get a free ticket. CHARLES: Nice. This is the problem with the internet is I'm always finding out things that I wish I'd known 10 years ago. I wish I'd known about this before it actually tried to do any open source. This is the Open Source Bridge so what's a sample of what you guys are going to be talking about? AUDREY: The thing that we've added this year and it's really exciting is the activism track. We're having a lot more people to talk about what they do as code. In this other way, more of public facing way. We have Nicole Sanchez from GitHub. She's going to talk about diversity inclusion and some of the biggest [inaudible] there. We also had Emily Gorcenski doing another keynote and she talks a lot about data and ethics and has a lot of interesting things to say about how we collect and sort and process information and the impacts of that. We have a couple of workshops that are really great. One on technical interviewing and the personal skills that you need. There is a session on keyboard hacking. CHARLES: Keyboard hacking? This is in the activism track? AUDREY: No. This are across all the tracks. CHARLES: How many different tracks are there? AUDREY: There's five. CHARLES: This is a big conference. AUDREY: Yeah. It is such a great community for me to be a part of. Like I said, the different kinds of projects that people come from and bring into it and the different skills, we'll have people that are everywhere from kernel hackers to working in devops to people that kind of fit, I think what we think of it are more typical like web developer or mobile developer kind of skill set. People who run their projects, folks from Dreamwidth often come and participate and they have a lot of really great things to share because they have such an inclusive focus on how they do their project. CHARLES: Where was that? AUDREY: Dreamwidth. It's a LiveJournal spinoff. It's online community journaling website. It's in Perl, which is cool. There aren't as many outward facing things, hiring Perl programmer these days, I think. CHARLES: It's still a very active Perl project? AUDREY: Yeah. CHARLES: Wow. I did Perl a long, long time ago. AUDREY: I think it's really useful to remember that programming languages never actually die. There is always code. JOE: There's still plenty of COBOL positions out there. AUDREY: Yeah. Actually my uncle is a COBOL programmer. CHARLES: Yeah, I remember it was only some statistic where it was something like five years ago, Java, Eclipse, COBOL is the most popular programming language. The cycles are much larger than we tend to think. Surfing on the beach as we do, not realizing there's a whole ocean generating those waves. AUDREY: Yeah, I think if you're in a certain kind of technology startup plan, there's always this push to go for the nearest and shiniest on the number of JavaScript frameworks that we've gone through in the last five years. You kind of [inaudible] of all of these things that come before that are still in use. What I really loved about doing devops is that all of this pieces are still in play and there's something to learn from that. If they don't die, you don't get rid of them. You just try to build on them and keep them working usefully. CHARLES: Right. Man, that's exciting, so you have a very, very huge cross-section of the development community. It sounds like participating in here which is a quality in of itself. That must give you a pretty unique perspective being with that level of cross-discipline. Are there any insights that can only be gleaned by being able to perceive it from that high of a level? AUDREY: Well, a big one is that we all struggle with governance. We don't really talk outside of just a couple of forms for events that focus on open source maintainers. We don't talk about the governance of projects, like who was in charge and how decisions are made. But it turns out that that has just an enormous impact on what a project can actually do and how it survives. I think I might not have seen that as clearly without having people from so many different angles participating. CHARLES: I'm just trying to think of keeping it in the area of web frameworks because that's something that I'm familiar with. If we were to compare, say the governance model something like React, which is basically whatever Facebook wants, versus something in the middle like Angular, which is like an explicit governance model but also is heavily influenced by Google, versus something like... I don't know, well something like JavaScript itself, which has an open democratic model but heavily represented by major, major, major companies, versus something like Rust, which is I certainly get the feeling is a very explicit, very democratic model. All of those seem to have achieved a lot of success and this seemed like a very healthy projects but on the one hand of the spectrum like Rust, you have the super-transparent, super-democratic model and then on the React side, you've got this authoritarian model. That's opaque. How do you reconcile that those are both successful? AUDREY: I think a lot of what actually determines this stuff is who pays the developers. In both of those cases, meaning projects that present information and decision making differently but there are corporations that pay those developers and that's where the primary source of that code. Because of that, really who pays the developers determines what gets made, what code gets written. In a way, they're both doing some of the same things. They're just not giving you inside into that decision making, in some cases. CHARLES: The decision making apparatus is there, I guess the thing is this transparency to the user base matter. I would say that the user base of a thing like React dwarfs the actual corpus of decision makers. That doesn't seem to be that that decision making process is opaque. AUDREY: Well, I might be opening too much of a larger conversation by saying this but if you're familiar with the idea of algorithm transparency, decision making is encoded into things like algorithms and when we can't examine them, then we don't know how that decision was made so we don't know what biases are encoded into it. The same thing happens with code in general. You might say, "Let the outcome of this and this working really great," but there are still biases and preferences that are encoded into that that you don't have insight into. If they start to ship the project in a certain way, that include some users and excludes others. Even on just purely technical levels, you don't know what. You don't know how they got to that, you don't know if they're going to keep steering in that direction. If you're one of those people that is starting to be excluded, you don't know what you can do about it. I've seen these kinds of governance discussion even happen within Ruby in Rails. CHARLES: Yeah, it does seem like these political questions come up constantly. I remember an example that leaps to mind is a project that I was involved with was the Jenkins project, which originally was Hudson, which came out of Sun Microsystems. When Oracle bought Sun, they were basically trying to, I want to say there's always three sides to every story but from where I was sitting, they were essentially trying to subvert the project to their own needs and end up being in a fork of the project. Luckily, there was recourse there where because it was open source and because it was mostly maintained by the community and not by the company, they were able to fork it. They changed the name. They changed the logo and that was the end of the story. There was a question of which fork would survive but that was resolved within probably six months. But Jenkins lived and I think it's better off for it but I guess maybe then a question that you can one kind of stress test that you can put like, "Is it okay to put weight on this technology?" What would happen? Would my community be represented and would I be able to fork this, essentially? Maybe in that sense, React would pass that test. In the sense that it would be reasonable to fork it or something like that. I don't know. I'm just thinking of ways to try and validate if something safe to use. AUDREY: I think it's really interesting that you commented on the new change and the logo change because those kinds of trademarks are actually the most readily protected of all of the intellectual property in an open source projects. If things are going to go off and become a community project and it's being released under some open source model, often where the corporate control stays over those assets -- the name, the logo, the graphics -- maybe even some of the work [inaudible]. You have to ask if that code is still useful without that infrastructure that they provided. If you take the whole codebase and you walk off and you don't have the same developers and you don't have the same, even hosting resources or whatever, is that code still useful to you? What if you use a bug tracker? CHARLES: Right, now you own it. What's the cost now of maintaining? And are you going to get a return on that investment? AUDREY: Yeah. There's been some pretty big open source projects that have struggled with that, especially for end user facing software. Those turned out to be easy things for community to pick up. CHARLES: Can you provide any examples? AUDREY: I'm thinking of some of the stuff that happened with Open Office LibreOffice. CHARLES: Yeah, I remember that. AUDREY: There's still two different batches of people working on this and from what I understand, a whole lot of intellectual property complications. CHARLES: Yeah, it's funny how sometimes, it would be interesting to see a case study of all the major forks and the outcomes of what they were. Some I can think of, there was a fork of Ruby gems, for example I think back in 2009 that went off and was mainly, I think was a way of protest. I think some of those concerns were addressed in the main thing so that fork ended up dying, then you got the fork of io.js, which was ended up. There was a fork and then a rejoining with the Node community but I would say it was an effective tool so there was a fork but then it joined. It was a source code fork but it was a political fork. Then you have the Jenkins fork where the fork basically swallowed its ancestor and there's all these fascinating outcomes and then you've got this LibreOffice Open Office where the waters are very murky about what happened with that fork. AUDREY: I heard people say like, "If you don't like this decision, then just go fork the project." CHARLES: Because that's easy. AUDREY: And if one of your major developers does it, then maybe, like you said, they have some leverage and they can make the changes they want to see happen, [inaudible]. But in general, that's a really hard thing to pull off. You've got to be able to take your entire community with you. Part of this is have to be functional and I think people are very rarely actually make that happen. CHARLES: Right. I feel like that's a dishonest thing to say when people are like, "If you want to go fork it," because really forking the code is the easy part. It's forking the community. AUDREY: Well, if you do that, then you've got a lot of conflicts. You've got a lot of people's feelings to address. It's not a very simple thing to recover from. CHARLES: Yeah. Some people do it. We have some good examples of that happening but it doesn't always pan out for the best. How can we make open source more accessible and supportive of contributors? We've mentioned a lot of that stuff in terms of how you can support people who are contributing but there might be more to talk about that. AUDREY: Yeah, we haven't really talked about who gets to participate. We talked about what kinds of things you can do when you see that people are interested but we don't talk about how in order to be a week encoder, you've got to have those weekends free. Certainly, I am right now. CHARLES: Yeah, neither do I. AUDREY: You have to have access to a laptop if you want to go to Code Sprints or [inaudible]. Not everybody has that, even people who are programming or your own computer not owned by your employer. That can be really important. You have to have a knowledge of how open source works. I do see fairly often in conferences that focus on a lot in open source, there will be how to become an open source contributor kind of talk. That kind of cultural knowledge is really important because otherwise, you're going to GitHub and you look at it and you say, "What am I supposed to do here? What am I actually supposed to do with this?" It's just a wall of information. There's something about a project on GitHub that creates these entry points for somebody who doesn't know how open source projects work. CHARLES: Yeah and it's so hard to be able to perceive it from that person's perspective, especially if you're frog-boiled, so to speak in the community. You've been doing this for so long, these things seem self-evident that it takes a computer, it takes the time, it takes knowing where to establish a toehold. These are all non-problems for you but they're insurmountable for someone else. AUDREY: There's one other aspect of this that we haven't really talked about, which is the friendliness to the kinds of contributors that you have, the diversity of the project versus the homogeneity of the contributors, whether or not you have a code of conduct and you know how to do something with it so that people feel safe and welcome in your environment. There's a lot of people that stay away from open source projects because all they've ever seen is harassment and that behavior. You can have a counterexample but if you don't have some mechanism for showing that that won't happen in your projects, then there are folks that are never going to submit about. They're never going to make a commit. They're not going to put anything on the wiki. CHARLES: Why would voluntarily subject myself to, if the only thing on the other end of the phone is pain? AUDREY: There are plenty of people that decided just to opt out because of that. If open source projects want to see more contribution, you have to be very proactive in dealing with that. CHARLES: Yeah, I feel like it almost would be nice to have some sort of training. Even if you have a code of conduct on your open source project, I think as you grow it from something that's maybe just one or two people to where there's a larger community, the first time you have a bad actor who shows up and start slinging turds, it's shocking and you're taken aback. But just as the number of people grow in a community, that is going to happen. It's just an unfortunate fact of human nature so not having to react to it, but be prepared for it, I think is something that's extraordinarily valuable. I don't know if there's a guide for that on GitHub or guide for that on anywhere else but I think it would be very useful skill to have. AUDREY: It's just very funny that you say this because this is actually a training idea. CHARLES: Oh, really? I promise there was no payment under the table to ask that question. AUDREY: Yeah. There was some consulting around this and I started a program with a local non-profit called Safety First PDX and what we do is train user group leaders, conference organizers, open source project maintainers on exactly that: what to do with their code of conduct to enforce it and help people feel welcome in their community. I worked through a really specific examples with people about how you respond, how you have this conversations and what kinds of things you need to do to protect your contributors who are participants and be really firm about what is next in your space. CHARLES: Absolutely a critical skill for any open source project, for any open source community, for any large accumulation of people. AUDREY: And GitHub made it very easy to put a code of conduct on your project now but without these kinds of resources, I think what happens is that people get that first incident and they panic because it is scary to tell somebody that their behavior isn't okay. To tell them that they might have to step away from the project or stop doing that or even leave indefinitely, those are really hard things to get started doing. I really enjoy doing the training and getting to walkthrough that to people. CHARLES: Are you going to be offering that training anytime soon? AUDREY: We just had one here in Portland last week. We're doing it a quarterly thing but I'm also really open to bringing it elsewhere like a place to host and some sponsorship that they can throw at that and people that want to take this. CHARLES: That'll be awesome. Maybe we can have you in Austin. AUDREY: [inaudible]. CHARLES: Thank you, Joe. Thank you, Audrey for coming on the show. AUDREY: Thanks. CHARLES: It was really great to talk to you. It's great to talk about your history in open source and the things that you're doing in the community, especially the insights that you have around running sustainable open source projects. Also, thank you for talking to us about Open Source Bridge which is, I understand coming up right around the corner. If you want you can go to our podcast page and there will be a link to get $50 off if you enter in the discount code 'PODCAST.' That's $50 off of your open source bridge ticket. Be sure to go check it out. That's it for today, from The Frontside. If you're interested in hiring us, we do have availability starting in July so reach out to us. All right, everybody. Take care.