Separate Community Resource pages

[coke]

We have two pages discussing Community resources:

https://raku.org/community/

https://docs.raku.org/language/community

[coke]

My recommendation is that we eliminate the community page from the docs site, and rely on the raku.org page. We can expand the contents there (perhaps adding a second page with the "list of bots" details, which do not need to be up front)

[JJ]

The Raku Advent Calendar kind of helps and complements documentation. It's probably better to just point to whatever is relevant from the page that needs to. So agreeing on this.

[JJ]

... Or maybe not. They are sufficiently different to merit being separate. I don't see any kind of redundancy, or confusion. I'm going to revise it, and update where needed.

[JJ]

Additionally, wouldn't this be better addressed as an issue in the doc repo?

[lizmat]

This issue will be discussed in the first Raku Resolutions meeting, see more information at https://dev.to/lizmat/raku-resolutions-17g7

[coke]

Note that the primary raku.org URL is now "https://raku.org/nav/1/community” - which is a different problem (that we lost the “good” URL during the recent raku.org update) - Raku/raku.org#240

[librasteve]

1. I strongly agree with @coke original thought to merge the doc community page into the raku.org community page

2. The current live site redirects https://raku.org/community to https://raku.org/nav/1/community

To elaborate Raku/raku.org#240

Currently an Air site has a canonical page/component naming scheme that goes like this:

• site
  • nav/1
    • community => community-page &basepage, &shadow
    • install => install-page &basepage, &shadow
    • etc
  • nav/2
  • ...

All Air::Component instances (Nav is such a Component) are auto-allocated a serial (0 is reserved for "there is only one of these").

All Nav targets are specified by a List of Pairs where the key must be unique. The key is then used to make a Cro route. The value is the Page or content Component that serves the response when the route is hit.

This way, everything in the site will have a unique route url and content items can become route targets later on without collisions.

Contrast this to Wordpress where the canonical name is the serial of a post item in the database. So, while Air (in conjunction with Red) can be backed by a database, the presence of a DB is not a must for small sites.

---

So, what is now needed in Air is an Air::Stub system where the Pair name (eg community) is then carried down to the route definition and can be associated with a certain canonical name. The attached image shows the wordpress stub options - so this is akin to the postname option in that list. This is also important for SEO so it has high priority.