OpenLint Office Hours #1

00:00:00Before the start: Hellos, the weather ("it's cold here, I had to put on a jacket for the first time"), Phil joining from his car, and Dimitri joining. Kin gives everyone a few minutes to join.

00:01:34Kin Lane: I am hitting record, just a heads up, everybody. So we have a name. That's the most exciting part. It's a very literal and boring name, but it's good.

00:02:00An attendee: I actually voted for it [?], so yeah. Me too.

00:02:08Kin Lane: Well, I love it. I'll say this again if anybody else joins and we recap, but people from SmartBear have emailed me and said they're still working on getting a decision, and maybe just handing over Spectral to the group. But I'm not holding my breath, because I know from experience I don't need to hold my breath. Several people have said that could happen, but I'm having déjà vu, because Swagger was going into the OpenAPI Initiative. It's all different people, so I don't blame anybody along the way. We had written the press releases and everything. They asked me to write the press release, and then at the last minute they kept the name Swagger and trademarked it, and said, "We're going to call it OpenAPI." And I said, that's such a horrible, boring name, no one's going to know what it is. I was so angry about it, I said I'm not sending the press release, and I got angry with the CEO then. So I love that this is a reverse of that: threatening to take it and name it something boring and leave the interesting name behind, but it's being done from the outside in rather than the inside out. So I'm having déjà vu, but it's kind of interesting. Welcome back, Phil.

00:03:59Phil Sturgeon: Hello. In my defense, I'm driving on a private track in a field, so don't worry about that.

00:04:04Kin Lane: Okay, I was going to shame you, but if you're in a safe space then I'm all right with it.

00:04:09Phil Sturgeon: Owning land [?] perks.

00:04:12Kin Lane: It's good. I don't think I've ever seen you driving. I've seen you ride your bike here in the States, I've seen you on your boat. You're always in motion somewhere. Hey Mike, welcome. We're still giving it a few, letting folks join, slow roll. We're just celebrating that we have a name now, so that's the first main item off the list. Asterisk: there's still buzz and talk about SmartBear handing over Spectral as well, but I'm not holding my breath and we're not going to wait. I was also celebrating that last time we ended up with the OpenAPI name because they kept the name Swagger back at the last minute, and now we're choosing the more boring open name and abandoning the cooler name, but we're doing it from the outside in this time, and it's a different game.

00:05:22Kin Lane: I think we're getting closer to a group here, so I'll go ahead and get started. Heads up everyone, I am recording. I consider this the first official office hours of OpenLint. We have been having them weekly, but they were more "what's our name, what is this". We do have that provenance, that history of conversations going back to Phil and me first talking, but this is the first official OpenLint office hours. Let me share my screen, because I loosely put together the agenda. I'll always pin it to the top of the issues, there will be an individual issue for each one of these office hours, and I'll do my best to get it up at least a day ahead, if not the morning of.

The first agenda item, which is not actually on here, is to acknowledge that we have a name now. We now call it OpenLint. That was done through voting, there's a provenance of that, and there are issues that track that history. Community-wise, it's interesting to watch it come together. Honestly, it's not the name I would have chosen. I never liked OpenAPI. I liked Swagger, I liked Spectral, I liked the flashier names. But after watching and living the OpenAPI success, even with all the Swagger problems, I feel like OpenLint is a good name. I've talked to a few people at different companies. I was talking to John Musser, who created ProgrammableWeb and is now at Ford, and he said, "Oh yeah, I can explain what that is to people who don't understand APIs or linting or anything, normal people. It's a good name."

So I went ahead and bought the website, openlint.org, set up the GitHub org, which we're in right now, and set up a community discussion repo. And yeah, I agree, Mike: Swagger kind of became a negative word after a while. It caused problems. I set up issues at that community repo for submitting issues, and there's an email address, [email protected]. That was ground zero. I didn't want to do too much. I set up a basic single-page website, the community repo, and the GitHub org readme page. But I don't want to move too fast for the community. My intention was to do this slowly over the summer and get everyone on board, and I feel like it was successful, because y'all are here, and a lot more people who couldn't make it have been involved. So I'm pretty happy with it.

I'll put the asterisk on it: we're still hearing that SmartBear might be interested in donating Spectral to the group, but I'm not going to stop or change what we're doing, and I'm not going to hold my breath, for many reasons I won't go into. If they want to, we can talk about that when it happens. Right now we have a name, we have a foundation, and we're moving forward. I'll pause there before I dive into the roadmap. Any thoughts, anything folks want to share?

No? What I'm going to do now is dive into the roadmap, which is intentionally broken into three areas. I'll probably keep these as the three defining buckets of OpenLint work: one, the specification; two, the toolbox; and three, the governance, or the administration of it. Administration is probably a better word than governance. I'll talk through each area and pause after each one so anybody can comment on what we're doing or on anything missing. Once we get through the three areas, Phil has started some discussions around each of the areas, which I'd like to dive into and give Phil some time to talk.

We just finished the recap, so here's what we have. Next is what I feel is one of the most important parts of this work: taking the specification, which right now is just a configuration of the Spectral CLI, and making it a formal specification. The first part of that is treating it as a formal specification: normative wording, versioning, and a process for doing that, treating it as a spec rather than just a configuration file or a JSON Schema. Two, building a tool conformance suite. Now that I'm reading it, I'm not sure that should live here under the specification; it should live under the toolbox. Three, rules testing: a formal strategy for testing rules, in a way the community can do consistently and reliably themselves, not just us. Four, multi-format: OpenLint is not just an OpenAPI linting tool. It will do any YAML or JSON, and hopefully more eventually, Markdown being one target. Five, aliases: being able to use shorthand aliases for referencing complex artifacts. Six, modular rulesets: being able to easily build rulesets that are very modular, and compose them as needed. Seven, federation: being able to federate rulesets, centrally manage them, but allow many different groups to implement them and feed back into them. Eight, industry rulesets: healthcare, FHIR, banking, PSD2 and beyond, geo, actual industry-level rulesets. Nine, custom functions: that's a top priority. What needs to happen there, and do we continue the way it's been? Ten, autofixing: deterministic as well as non-deterministic autofixing of artifacts based on rules. Eleven, a rating system: being able to assign points to a rule, have those roll up and get applied to an artifact, and have some sort of provenance for that process. Twelve, CI/CD. This isn't the implementation; the CI/CD pipeline implementation is down below. This is linting of CI/CD pipelines and artifacts, having a specific class of rules for GitHub Actions and those kinds of things. Thirteen, being able to apply overlays to rules: using overlays to change the behavior or functionality of rules, for localization and all the same reasons you would overlay an OpenAPI or an Arazzo document. And fourteen, education and training: how do we teach people about rules?

Other than the tool conformance suite, which I'll move down to the toolbox, that's what I had gathered from previous conversations and the current work. Mike, what have you got?

00:14:31Mike: One of the things I think is really important, and I'm not sure if it falls into the specification or the toolbox, is integration into IDEs. The VS Code extension, for example, is something I've used heavily, and I just want to make sure we get some focus on that somewhere as we go forward.

00:15:02Kin Lane: I agree. I'll have to think more about this, but I feel like it fits in both the specification and the toolbox. It would be part of the toolbox, but I think there are specification-related things, specifically in VS Code, and then we'll have to explore others. We just saw the latest JSON Schema draft get accepted into VS Code. We've been waiting for that, and it impacted OpenAPI, which impacts this. So I think what you're saying fits into both. Any other thoughts on the specification? That's a pretty big laundry list. I'm sure there are other things, but I'll add IDE to it, because IDE is definitely worthy. I can't imagine we're going to get it all done this month, let alone next month. No, I'm just kidding. It's going to take us a while.

Oh, sorry, sorry, Karyan [?]. Go ahead, Dimitri.

00:16:24Dimitri van Hees: Perhaps it's a no-brainer, but it's still worth mentioning: the specification should also be AI-friendly, right? So perhaps we could also provide a skill or whatever.

00:16:38Kin Lane: Ah, yeah, prompts and skills. Agreed, I'll add it to the list. Phil, did you have anything you wanted to add?

00:16:56Phil Sturgeon: I was wrong. I was going to talk about ratings, but number eleven, ratings, it's on there.

00:17:03Kin Lane: Okay. And this isn't fixed. This is the initial roadmap, and we'll talk about how this becomes the roadmap next, but this is just our starter list. It can change, we can inject anything later on, and we can deprioritize any of these. It's just our starting point.

Moving to the toolbox. This is what was formerly known as the CLI, but we're not calling it the CLI, because it's much more than that. These are the roadmap items to iterate on the toolbox, which is a separate set of work from the spec. It'll likely be a different group of people, different meetings, different discussions, issues, PRs and repos. First and foremost, the core libraries: making sure the core of OpenLint is clear, very explicit, the starting point, what needs to be present everywhere, with the rest being very modular, so people can pick à la carte what they want and what they don't, with a clear distinction between the core libraries and the modules. And this work requires cleaning up a lot of the Stoplightisms that are in there. Folks who've come from the Stoplight world know what's under the hood. I think those top three are the most important: getting the core set up, making things modular, and cleaning up the Stoplight stuff.

A rules builder: a clear set of tools for building rules. A clear, coherent default ruleset that isn't just one format but reflects what the core set of formats are, and again doesn't have a bunch of Stoplightisms or other vendorisms in there. We'll probably use the word vendorism instead of Stoplightism, because we don't want to prevent any vendor from having that gravity down the road. Format auto-detection: it'll auto-detect the format and work from there. We're going to replace the JSON Ref bundler that's in there, but there's probably a lot of other library work that needs to be gone through, including removing telemetry and getting supply-chain health to an acceptable level. A CI/CD pipeline package: how do you implement this in the top CI/CD pipelines, with clear guidance, tooling and packages for people to do that. Migration support: how do you migrate from Spectral to OpenLint? We want to make that very clear, simple and easy. Then we want to pay attention to Spectral upstream. We've got to come up with a plan: how much do we pay attention to it, or do we just blow past them and not worry too much? I think there need to be ongoing discussions about this. Then the implementation landscape. OpenAPI really dropped the ball on the tooling front when it came to how you implement OpenAPI. I won't go into all the reasons for that, but I think we need a really strong relationship with the tooling and service landscape, the commercial and open source solutions. And then Docker. I know there are different, more logical approaches to the Docker implementation, making it cleaner and thinking it through.

That's the core of the toolbox. I'll move the conformance suite down here and add an IDE item as well, so we'll have the VS Code plugin and a conformance suite. I think the conformance suite will weave into the implementation and tooling landscape: how all the vendors and tools size up. Any thoughts? Anything missing? Go ahead.

00:21:58An attendee: I think the conformance suite could have a part that belongs to the specification. The conformance suite is a piece of software that verifies the compliance of implementations, but it should perform tests that we could formally describe. So we could have a formal set of compliance tests described in text, in the specification or in a separate document, and the compliance suite would be the implementation of those tests.

00:22:43Kin Lane: I agree with that. I think you're right. I'll leave it on both. It's kind of like IDE. Any other thoughts? Anything else missing? Go ahead, Dimitri.

00:23:06Dimitri van Hees: You talked about migration from Spectral to OpenLint. Perhaps we could also add migration from Vacuum to OpenLint. Are we able to get them on board as well? Because basically it's a Go implementation of it.

00:23:21Phil Sturgeon: Yeah. They've expressed an interest in getting involved, and when it comes to improving one standard DSL, they're interested in that as well. I don't think they're closing up shop, but it could just be the Go implementation of the same stuff we're deciding here. Then we can get rid of the differences between the rulesets, which would be nice. We don't want this to be the XKCD comic of "now there are 14 standards". This would erode the existing number of vendor implementations by making the standard way for them all to do it. There are just going to be backwards-compatibility issues to think about there, but we can be smart about it.

00:24:13Kin Lane: Okay. Hearing that, I would say eleven, twelve and thirteen all get collapsed into one, and I'll come up with a better word, because there really isn't migration. Spectral upstream should be part of it, and the implementation landscape should be part of it. Ideally, if they don't donate Spectral and they keep working on Spectral, we would love for SmartBear to keep using this, use OpenLint, and for it to be a two-way street. I don't know if that'll happen. Same with Dave and Vacuum: we want that. One of the things that bothered me with Redocly and APIMatic [?] is that they had migration paths. They didn't say "we support Spectral rules"; they supported importing Spectral rules, and then you use their tool. I want to change that behavior. I don't want migration support; I want interoperability across the landscape, and conformance that fits with that.

00:25:21Phil Sturgeon: Yeah, I think Speakeasy supports some of the Spectral ruleset as well, and I'm sure they wouldn't be against switching over. So there are plans to work with as many tooling vendors as possible, and those that aren't sat in the room right now are at least in our DMs.

00:25:38Kin Lane: Yep, and that's what spurred this. I was talking to several folks at several companies, and I was looking to soft-fork Spectral myself for my own needs and take it down a different path, and I saw that being a bad decision. So I'll collapse eleven, twelve and thirteen into something like "ecosystem support": how does it work with tools, how do we keep an eye on what SmartBear is building, how do we certify the landscape and ensure the landscape is conforming. Anything else on the toolbox? Again, this isn't an exhaustive list. We can add to it any time. It's just our priority list.

00:26:36Phil Sturgeon: Something that was mentioned in a previous meeting was documentation generation tools for the ruleset: making it so the ruleset can be bunged through a tool, much like you bung an API through a tool, and actually get some documentation that may or may not integrate with popular tooling. We've already got the standard Spectral documentation where you put a good example and a bad example, and that could even be part of the tests as well. So, working out how to make documentation easier and not a manual copy-and-paste exercise, which is very boring.

00:27:12Kin Lane: Agreed. I'll add that to the list. As you were talking, I had another idea along the same lines. I'll probably add an MCP server and an API, because I have an implementation where I'm able to work with Spectral programmatically, so I think that'll be part of the tooling, as well as the docs. Yep, integrating the docs with tests. And for the CI/CD pipeline package, getting the testing in there in a coherent, clear, standardized way. Postman used to have an HTML reporter for their command-line tool, the one they killed off, I forget what it was called. Anyway, it had really nice visual reporting, and that's something I'd like to bring into this when it comes to testing and conformance. The ruleset you're running against these artifacts: what does that testing look like? And the ruleset itself: how conforming is it? I want that to be a whole package deal. Anything else on the toolbox?

00:29:05Mike: Do you have coverage tools on there somewhere?

00:29:08Kin Lane: I have it on my list, but I didn't have it on here. I have a coverage solution for Spectral that I use, but I can add it to this list if you think it's worthwhile.

00:29:21Mike: I think it is worthwhile, yeah.

00:29:23Kin Lane: Okay, I'll add it to the list. That's an important one for me. When I was doing this at Bloomberg, I had different rulesets for different domains, so you could build modular rulesets by the team or the domain you were in, and then run them. And some of them just didn't have coverage across the OpenAPIs and files they were running against. They were very lightweight, and they really didn't mean anything. So coverage is pretty key.

00:29:58Mike: What I'm thinking is, I've written tests for my Spectral rules, but I don't know that I'm really testing all the variations with those tests. So if there were some way to, and I don't even know how to qualify this, test that you've exercised all the givens, for example. My tests generally have a negative test and a positive test: they find the error, and they don't find the error in cases where they shouldn't. I don't know if there's a more sophisticated way to think about coverage than that, but it would be nice to have some automated way to check it.

00:30:57Kin Lane: Yeah. I had coverage that was based on tags. I would have a tag, say documentation: these rules all apply to documentation, so how do we get 100% coverage of all the documentation rules in this OpenAPI? You could group and color-code coverage by the area that mattered. So coverage is a way of validating the strength, the maturity, the quality of your ruleset, especially when it's modular. I think having programmatic assistance on that is going to be key.

00:31:49Phil Sturgeon: Would I be right in thinking those are two different types of coverage being discussed? Mike, I feel like yours is how much of my custom functions, or how much of the DSL usage, how much of the rule logic is being tested in this test suite. Kin, you're talking about how much of these rules are being applied to this document, because you can get a pass after it's missed every single possible rule. There are two different features, I think.

00:32:23Mike: I agree 100%. I think you're right, Phil, and I was thinking about that too. When I was talking about it, you can imagine saying, "Here's my ruleset, and these are the rules that haven't been tested." But what Kin is talking about is, "Here's my OpenAPI document, my end document that I'm linting, and here are the parts of that document that I didn't actually validate."

00:32:46Kin Lane: Yeah, I'll make sure that separation exists in there. Anything else in the toolbox?

00:33:02Phil Sturgeon: You've got to stop asking for more things, man.

00:33:04Kin Lane: All right, moving on. The governance, or the administration, of this project is this area. First is governance: how are we going to govern? I'll put together a document and we can discuss it. The document I had already put together was based on squinting at the governance of OpenAPI, AsyncAPI, JSON Schema, MCP, all the specs, and making some proposals for how we would do it here. We can tackle that independently.

Then who the maintainers are. I feel like everybody who's been involved from July until now is somewhat of a maintainer, and I'm going to put them on the maintainer list, and then we can hammer out who's actually an approver on the repo, who's actually stepping up to do work. Some people said in a meeting a couple of times ago, "I'm more interested in the tool" or "I'm more interested in the spec". I would say I'm more interested in this part, the administration and the overview, than in the other two areas. So we could maybe have maintainers for each area, and they can overlap.

Next is the home: where is this living? Right now it's on track for Open Source Europe, which Łukasz Gornicki proposed. There's a video that walks through the pros and cons of why it's better than the Linux Foundation and better than the OpenAPI Initiative, and I don't have any strong arguments against it. It feels like the place to be. I think the majority of the folks on this call are European-based, and there are a lot of sovereignty reasons to have an open source specification that manages governance centered in Europe right now. So unless there are any arguments, we can go with that as the home. I'll fire up a discussion and an issue and we can move forward with that.

Funding: I'm just going to set up Open Collective for now, and then I'm going to start chasing sponsors, because my first goal is to get some money in the pool. There are other funding issues we can address independently.

Licensing: we just carry forward the licensing that's applied to Spectral right now, because we're forking it and we have to. For other content, the website, the trademarks and other things, we can address those independently.

Then I wanted to acknowledge the use of AI. And I should probably have an eighth item on here that's process. It's based on what Phil already started. I'm very issue-based, and most of the items on this list will eventually get an issue, which becomes a pull request. But per what Phil did, I feel like everything should start as a discussion. Once you know who the stakeholders are and what the discussion is, the issue or issues get created, those can be grouped, they go into a pull request, and the pull request can be the work. So, loosely keeping with that as the flow: start things as a discussion, figure out who the owners are, they organize the work as issues, and they do the work as pull requests.

AI: I don't think there's any avoiding AI in this. Another footnote: I'm sitting in on all the specification meetings right now, MCP, A2A, OpenAPI, Arazzo. I'm listening in on them all; this is the only one I'm running. And everyone, even people at Anthropic, which I find super ironic, is saying please back off with the AI stuff, the AI issues, the AI noise. At OpenAPI, people at Microsoft are saying, "Can you chill? Can we do shorter ones if you're going to do it with AI?" So I don't want to use AI if we can at all avoid it, but I feel like there's a lot of work here that will need AI. My proposal for the use of AI is that we use it wisely and minimally, and if you're going to use it on an issue or a pull request, you have all the other stakeholders on there in agreement that you are, and on what it's used for and how. We leave that on a PR-by-PR basis. But I'm not going to use it on issues here, because it tends to create very chatty, long issues that people's eyes gloss over. I'd rather keep it short, concise and human-based. I'd love to hear everyone else's thoughts, but that's where I've landed from working across the other groups.

00:38:32Phil Sturgeon: Yeah, I feel like with a lot of this planning stuff, it's important that we're conveying intent and meaning, not just a bunch of words. The issues I've started are pretty basic, and there could be more information in there, but I don't think it would have helped if I'd bunged them through the slop box. I'm thinking: paste your prompt, not the result. There are things we need to find out more about, things we need to dig into in the code. We can just do that, and then we're learning, as opposed to just firing walls of text at each other.

00:39:08Kin Lane: Amen. I feel like for cleaning out the Stoplightisms in the tool, AI might be of some help in pointing to some of that work, and to some of the other rules-based and skills-based work. But we've just got to be intentional about it, like you said, Phil.

00:39:36Phil Sturgeon: Yeah, I think that's why I jumped straight in and started with a discussion for aliases. But then with cleaning up the Stoplightisms and stuff, I've been trying to do this for years.

00:39:52Kin Lane: Yep, agreed. That's the administration section. Anything else? I won't ask more than once. Just leave it open, and we can go asynchronous from here.

I'm going to start discussions. I'm going to clean up a couple of these, like the migration one I mentioned, and start discussions for them and link them here lightly. Each discussion will start with me manually adding my thoughts and where it's at. Then when I want to pick up work, or anybody picks up work, you can signal it in the discussion, start issues and start drafting that work, then craft pull requests to do the work and set up repos for it.

One last thing on administration: let me know if you want admin access. Everyone here who's been involved I consider a maintainer, and I'm happy to give admin access to anybody who's been doing this work, but I'm not just going to give it to everybody out of the gate. Phil, you're getting it, you don't have a choice. Let me know if you want it and I'll give it to you, and then on a repo-by-repo basis we can decide how strict we want to be with reviews and approvals. I don't want to get too bureaucratic, but you know how this is; we do need it for some things. So I'll fire up discussions for all of these. There are a couple of areas I want to own when it comes to the work, and I'll start prioritizing this list, because I feel some of these things aren't going to get done and aren't going to get a champion and will fall lower, and some of them have to be done, and I'm going to drive those forward, start the issues and start doing the work. With that said, go ahead, Phil, take the stage.

00:42:04Phil Sturgeon: You're going to wonder about my pet peeves. One thing that would be really handy is if we could start off with a code of conduct as well. Whenever you start a new community, it's really helpful, rather than trying to wrestle it in later, and it generally keeps some of the worst people away, so we don't have to start talking to them in the first place.

00:42:22Kin Lane: Amen, will do. I'll add that right away. Can you talk about your three discussions here and walk us through what you're thinking?

00:42:33Phil Sturgeon: Oh, yeah, great. Aliases: give it a quick click, because there's a code example on it. I actually couldn't find aliases defined in the code. I seem to remember them being there, the idea being that not everyone wants to write JSONPath, filtered [?] and mixed with regex and God knows what else. Some people just want "all the header values", "all the header names". So you can give quite complex concepts a nickname that you can then reuse, and you can still do some JSONPath off of that. It's got this beautiful syntax: if you look at the info description, you can see it's using the hash to reference an alias and then going info.description. So that's referencing the info alias and extending it with .description. This was always destined for Stoplight core, to be the main way of avoiding JSONPath while still allowing JSONPath for advanced use cases. I think it might only have made it as far as the hosted Stoplight platform, which a lot of people don't use. I literally could not find it in the code. There are tests that test the logic works, but there is no standard list of aliases.

So I think it would be a really good idea for us to start doing this, and instead of wedging it into the Spectral OAS ruleset, where if you extend that ruleset, which everyone does, you can't access them. It currently only helps the person who made that one particular ruleset. Really it should be how everyone uses it, for everything: OpenAPI, and then AsyncAPI has one. Whenever we define a format that OpenLint supports, we should define a standard list of aliases for it. And we could work with Redocly, who already have names for a whole bunch of stuff, and say, "Can we work together to use all of those named properties?" That would make it a really easy migration or switch for them to come across, instead of making our own, or finding whatever the Stoplight platform had and copying that, or some superset. This will hopefully solve the problems of JSONPath [?], because you just don't have to use it.

00:44:48Kin Lane: I love it, I'm all for it. This one makes me happy. The number of times someone's said, "Oh, I don't use Spectral because of JSONPath." It's right up there, second only to people who tell me, "I don't use OpenAPI because it doesn't do what I want it to do." And I'm always like, have you shown up to a meeting? Have you created an extension? Anyway.

00:45:17Phil Sturgeon: Yeah, I had a gas leak on the boat recently, and it reminded me of when I spent a lot of time writing Spectral rulesets. I felt about the same.

00:45:25Kin Lane: Cleaning up Stoplightisms, any thoughts on this?

00:45:29Phil Sturgeon: This is a list of rules that really have no relevance to the OpenAPI specification or any concept of validity, other than stuff I put into Speccy that was then copied from Speccy to Spectral, or stuff Stoplight added to Spectral shortly after. These are nice to have, but they don't make sense there. A lot of them actually fall under good documentation rules. There is already an official, but not included, spectral-documentation ruleset of "if you do all these things, your docs will look great", particularly in Stoplight. So moving some of those over to something more generic and vendor-free, "this will generally work really well in pretty much any documentation tool", would be a really useful functional ruleset to have: do this if you want your docs to look better, and it'll work pretty much everywhere. Most of them made it across, apart from one rule, operation-singular-tag, which sounds like something Trump came up with, but it's literally a pointless rule that says you can only have one tag. With OpenAPI 3.2 giving you lots of different kinds of tag, we should just delete that, because people are going to have a beta tag and a domain tag and a navigation tag and whatever else.

00:46:44Kin Lane: Yeah, agreed, I like it.

00:46:48Phil Sturgeon: For anything backwards-compatible, I'm thinking we could easily have... Currently you have to specify that you want the spectral:oas ruleset. We could very easily have an openlint:openapi, because people don't know what OAS is. You could have that new ruleset, which is pretty much a carbon copy with all the cruft knocked out, and keep the original one around as a compatibility layer, so anyone who's got spectral:oas written in gets the same functionality by default. Anyone starting fresh doesn't need to mention it, because we've got auto-detect, so it will just work out what to do.

00:47:19Kin Lane: I love that. Make sure backwards compatibility is part of our governance here too, because we want this to be seamless and pretty easy for folks. Rules testing.

00:47:40Phil Sturgeon: All right, I'm just showing off some of the nonsense I've been doing for npm-based Spectral rulesets. This is getting at what Mike was talking about. Just picking one: the rule there is called no-global-versioning. There's a document that is the valid case and a document that is the invalid case, and it says this one shouldn't make an error, that's why the errors array is empty; this one should make some errors, and here's the message, the path, the severity or whatever. So I'm trying to find a way to move that into a less language-specific format, much like the test harness already is, if anyone's familiar with that in Spectral, but moving it into the rule a bit, with the good and bad examples, so the documentation can use the good and bad examples, the tests can use the good and bad examples, and everything's in one format, instead of a really janky npm package that a lot of people don't know how to install.

00:48:40Kin Lane: I like it. That happy and unhappy path is going to be key, combined with the coverage.

00:48:48Phil Sturgeon: Yeah.

00:48:51Kin Lane: Nice. All right, these are the first three discussions, and I'll link them up here to the items and make sure they're the first pieces. Then I would say the formal specification, standardizing this as a formal spec, is a must-have starting point for a lot of these, because until we have the spec and the repo in place... So I'm going to move forward with that work. The core libraries have to move forward before all of this; we need a repo with the code in it. So I wanted to ask: what does forking Spectral technically and explicitly mean? Do I download the current Spectral as it stands today and make it the first commit on a clean repo? Or is it a true fork? Let's be pedantic about this.

00:49:57Phil Sturgeon: Are you asking right now, or are we going to come up with that sometime?

00:50:00Kin Lane: I'm asking right now for any opinions, but I'll start a discussion. It'll be the first thing in the core libraries discussion.

00:50:05Phil Sturgeon: If we click the GitHub fork button, you get the "forked from" picture, which just looks a bit funny, and it can be tricky over time. But if we make a new GitHub repo and haul over all the history, that makes it a lot easier to migrate changes over, because we can literally cherry-pick fixes and do some git magic on those bits, without forcing us to download everything, which is what will start happening if we just start throwing diffs at each other.

00:50:40An attendee: I would also be for just making a copy of the code and checking it in, perhaps with history, but not forking in the official GitHub sense. Forking in the official GitHub sense is useful when you intend to stay in sync and update and that kind of stuff. If we're not intending to do that, I think forking sends the wrong message.

00:51:07Kin Lane: Agreed, and that's what I wanted to avoid. So I'll fire up a core libraries discussion and start with this as the seed, and we can continue it there and start firing up issues to do that work. I just want to be very thoughtful about it. How many people are going to be racing to remove the telemetry from the new OpenLint? Pull requests all at once, get out of here.

One more I don't have on the admin part is the website. I just realized. I'll add the website here, because we want to communicate this in time and in motion, and that'll be an administration one. Thanks for these three discussions. I'll fire up a handful of others. I'm not going to fire up discussions for everything; I'm leaning on the people who care about those things to start the discussions. But I'll get the core ones started, formal spec and core libraries, as well as code of conduct and governance, those foundational ones. Once those are in motion, I'll start cherry-picking the other ones that matter to me most. But I encourage anyone to start a discussion on any of these that matter to you and that you'd like to be part of the work on, either leading it or just being part of it, championing it, because I'm hoping this will be a community effort. I want to be the admin until we get it into a home and get some money, to pay Phil, to pay me, to pay someone to help facilitate these meetings. But I don't want to own it, so I'm going to rely on all of y'all to help champion things and be that change.

00:53:00Phil Sturgeon: Nice. I'm going to take the two that were issues and turn them into discussions, if no one beats me to it, and then I'm going to open a few new discussions on a few of the things I care about more. If anyone throws a discussion into the comments, I can link them up to the list, and we'll get a discussion started for everything on the list. So everyone go nuts.

00:53:29Kin Lane: Excellent. That concludes the first OpenLint office hours, and we're off and running, working on the roadmap. Anything else, y'all, that we should be thinking about? I'll add one footnote. What am I doing next? I'm doing A2A calls next, and the OpenAPI TSC next. I'm going to be bringing cross-pollination: I feel like there's a multi-spec opportunity here, and I'll be feeding that into the multi-format discussion and the work that happens here. I think there's a lot of gold across these specs right now that people are going to miss, because everyone's gold-rushing on A2A and MCP, and I'm going to be the old-timer who mines those gold bits. So I'll be bringing those in the future.

00:54:32Phil Sturgeon: Nice, that's a bit different. I've got a tree with ash dieback that I need to go and fell, because it's leaning over a track, so we've got pretty different lives right now.

00:54:40Kin Lane: All right, well, I expect you to bring stories back from that as well, Phil, and we'll meet in the middle.

00:54:49An attendee: Thanks for doing this, it's great.

00:54:50Kin Lane: All right, thanks, y'all. Bye-bye, thanks, everyone.