Emh, no. I think it’s pretty clear from the above that I strongly proposed YAML (or JSON) in Discourse posts for all flow of structured data from Discourse to webkit software. And then there was no reaction, so I just remembered today to bring this up again.
Let’s ascribe it to miscommunication. For the future: when I really want something adapted in a software design where it’s not my role to finally decide it, I usually frame it as a proposal and indicate that I really would like to see that happen. That’s just about being nice, playing part of the team rather than commanding people around or showing disregard for their software design skills. But I only propose something that way if I think it’s significantly better than what I have seen so far (and here that includes the event and team tagging in Owen’s earlier iteration of webkit-like software).
So please, for the future, take this kind of change proposal seriously. Otherwise there will be a mess later and we’ll have to change things around to tidy up, anyway. As for myself, I’ll try to remember that I better tell that something is unacceptable here in Discourse (rather than making a constructive proposal for an alternative that is then ignored as a mere suggestion). My role here is to tidy up and keep Discourse organized, while yours (for this project) is to find new uses for Discourse. Both has its place …
Tags are just a selection mechanism for topics. So by switching to another such mechanism, no need to re-do much of the implementation.
For example for events that are about displaying a feed of events collected on the Discourse platform anyway, the mechanism could be:
-
all topics from a category, such as “Internet of Humans → Events”, that have a date field set using the Calendar plugin
-
all topics tagged event plus project-ngi-forward
Both of these are mechanisms already in established use on the platform. One of them uses tags, but these tags already exist and are useful for users of the Discourse platform. So if one of these is a sufficient solution for the use case, no need to invent anything new or to introduce redundancy. “Find the system, follow the system.” In fact, the more a website is generated from organic content found in Discourse rather than from content specifically written for that website, the better – because that’s the unique ability of the webkit, beyond just serving as a text editor for website content.
However, for the events that seem to be the common case for the NGI Summit website (like this one), my above proposal of using YAML inside Discourse posts seems more appropriate. It’s exactly made for cases like this. I would put the whole conference schedule into one YAML block, similar to putting a whole team into one JSON block here. Reasons:
-
These are rather short session descriptions, not something that you expect Discourse users to extensively comment on. If you’d want comments inside Discourse for this content, of course topics would be the way to go.
-
They contain some structured information like “Location: […]” and “Speakers: […]” that lends itself to YAML much more than to a messy parsing of Markdown / HTML to extract that information from post content.
-
Since these are small chunks of content and usually will get no comments on Discourse, it is wasteful to represent them as topics in Discourse. Topics are the second-highest level of structure in Discourse (below categories), so creating a lot of topics where there is no need means a lot of structural clutter. It’s like having a PhD thesis with only first-level headings and paragraphs and nothing else. Instead, when structuring something, I always try to find the adequate means within the toolkit of whatever is available to structure information in a software.
I think that this point applies even when it’s about content that is “only” meant for being displayed on an external website, with little relevance inside Discourse. Because: this content has to be in a public category to be accessible by the webkit, so you can’t keep these topics out of people’s “New” and “Latest” lists. When using (for example) posts inside a single topic for this content, these lists would be much less cluttered for users. In order to make the webkit a useful Discourse-based CMS product for wider use eventually, I think that’s an important point to raise about its interaction with Discourse.
tl;dr Selection by tag is fine for tags that serve a purpose for Discourse users – so keep that feature around. But I’d generalize that topic selection mechanism to also allow filtering by category, by availability of a certain custom field, perhaps by topic author, perhaps by is-wiki state. The advanced Discourse search function is your friend for this. For all remaining cases, custom Discourse tags can probably be avoided by the YAML-inside-Discourse scheme I proposed (plus hardcoded topic-and-post references in the webkit site’s configuration file). No issue if you have to do the NGI Summit with the custom tagging as started now, but please try to make the transition directly after that.
P.S.: The use of the ngi-summit-stories tag is indeed a pretty good use case for a Discourse tag. Because it’s working on organic content of the platform that may appear in any category, and there are few tools beyond tags that could be used to mark it. My only comment here would be to not tie the tag name to a specific event, but to frame it with future re-uses of that tag in mind, including for users of the Discourse platform itself. So maybe #ioh-featured or #ioh-featured-story would do?