- From: Dan Brickley <danbri@danbri.org>
- Date: Tue, 16 May 2023 23:21:58 -0400
- To: "schema.org Mailing List" <public-schemaorg@w3.org>
- Message-ID: <CAFfrAFqBvq-wyonhhH3bNRODB-CE2b7VkC7sJBDtzv0PnC8fWA@mail.gmail.com>
See https://schema.org/ and https://schema.org/docs/releases.html for details. From this release, the Schema.org workflow is simplified. Roughly - we discuss things here and in Github, and the main schema.org site is periodically updated. There is no reason for updates to sit around for weeks or months while a larger release is put together - if something is a fix or improvement, let's push it live asap. In the (reasonably rare) cases when a bad change is made, we can follow up with good changes immediately afterwards. Our history since 2011 is pretty clear: there are always bugs, releases have always improved things, and conflicts are rare. I and others have found that the combination of (a) having an editorial drafting/staging site at webschemas.org (b) the remnants of our old subdomain-based extensions system ("____.schema.org" URLs e.g. pending.schema.org) and (c) the "Pending area" concept itself, taken together, tend to cause needless confusion, and add friction to the development and maintenance process. They also create technical debt and conceptual complexities that make it harder to share the workload with community members who have not spent 10+ years on the project. I shall try to put this into practice and make some additional changes (for consistency with the above, as well as addressing open issues) over the coming days. For each release, we should just increment the release counter by one. A release for this kind of a project should not be a big occasion but a natural and frequent side effect of maintenance and improvement. cheers, Dan
Received on Wednesday, 17 May 2023 03:22:17 UTC