Webkit Dev Report [22/2]

[owen]

Thanks @nadia

@nadia

Pages ” - When you write this, are you referring to topics on the platform from which content is picked up, the final display of contents from a category or something else?

Yes, it needs documenting, but for now:

• A page is an individual site, such as this site.
• The configuration of that page is the topic on discourse, from which that page gets its content - so for the aforementioned page, this topic.
• A collection is a way of bringing pages, conversations, teams, events and more under one umbrella. As we agreed in our call, categories provide the ideal scaffolding for this.
• So a collection is configured by a category on discourse. In this example, this category.

If I were to move the site mentioned above to a different collection, it would involve moving it to a different category on the platform. If I wanted to modify a collection name, icon, description, color, I would edit the category on the platform.

Collection URLs

The category slug slug is the last element of the path of a category. In the case of OCI lab, you see the slug in the last part of the category url: https://edgeryders.eu/c/ocilab => ‘ocilab’. So that is by default the url path of the collection. Once we set this up on its own domain, the project will be at domain.com/project/ocilab. And so on.

@nadia

Directory/Sitemap of what is where and how to edited it - this ought to be done at an early stage as without it we are completely lost in managing these pages (or even knowing which ones exist at all):

All of these things can be generated automatically by the site, and it is a much better solution than manually maintaining a list. So I will add this as a feature: when you go to the site and add the path /sitemap - you’ll get a page displaying a link to the configuration topic, a list of all linked topics from that site (JSON data and whatnot), as well as tags, partner accounts, etc.

@nadia

“Team” - this is intended to be determined based on platform user’s permission level. However, this is for the entire platform. There will be different teams associated to different projects. So how do we deal with this.

As you mentioned before there are admin roles associated with each user. The problem we will have is what if person X is an admin on the platform, and part of a category (having contributed once to that category) - but not technically on that project’s team. For example: I post in the OCILab category, I’m not part of that project, but if the project page sees I’m an ‘admin’, it will think I am. So we have to figure this out. If you have any ideas let me know, but I’m pretty sure we can find a solution.

@nadia

• Tell forms: does any of this affect tell forms? If yes, how?

Not functionally - they can remain as they are. But eventually there will be a decision on how we integrate forms in a collection: we can group them all together in one category and they can be displayed as one ‘forms’ collection. Or we can have each collection detect the forms in the collection’s respective category, and display them, like pages, events and discussion, as another section in the collection.

@nadia

Stability - We need to have a clear timeline for how long this setup will remain the same without the kind of changes as took place between webkit 1.0 and webkit 2.0. And for how long there will be reliable maintenance of the setup.

This will be the final big part. I’ve done a lot of work on this and it’s been a tough project to implement right… I think this is the closest we can get to something that, while complex, can be understood and used in a simple manner.

When it’s ready my plan is to create a dedicated webkit collection with its own pages for documentation.

Once that is done and the core features are finished, the only changes will be progressive enhancements: adding support for events, media, etc. But nothing new or changing any syntax.