The first four

Source: Dev.to

Follow‑up on Raku Resolutions

The first meeting was held at the suggested time and date: 17 January 2026 at 19:00 UTC.
Besides the four Raku Steering Council members, up to eight other people attended – thank you for your participation and feedback.

Issues discussed

Four issues were covered within the allotted hour, and one additional issue was explicitly moved to the next meeting at the request of its issuer.

1. Specify documentation URLs

Richard Hainsworth explained the background:

• When the Raku documentation was created, methods sharing the same name were grouped automatically (e.g. the documentation of the print method).
• Over the years, the pre‑generated pages accumulated inbound links from other parts of the documentation.
• The URLs of those pages can shift, causing links to break.

In the new Raku Documentation rendering (based on RakuDoc) this will need to be handled programmatically, which also requires some cleanup.

Decision: Close the issue for now, with an explanation of why. A new documentation issue can be opened later if needed.

2. Generic name for FALLBACK and CALL‑ME

A lengthy discussion revealed that a generic name such as “hook” would not be suitable from a documentation perspective. It also became clear that none of the participants had complete knowledge of all the nuances of these special cases.

Elizabeth Mattijsen suggested:

Someone should write a series of blog posts about these special features, categorising them by when they are called, what they do, and whether they can be customised/overridden by user code. Those posts could then serve as a basis for extended documentation.

Decision: Close the issue with a mention.

3. SEO for the keyword “rakulang” seems poor

The group agreed that this has become a non‑issue six years after the original posting.

Decision: Close the issue with a mention.

4. Seq vs. List – Iterable, instead?

The discussion highlighted two points:

1. The topic has both documentation and spec‑testing (roast) implications.
2. Changing roast expectations would constitute a language‑level change, because it could affect existing code that relies on a mutable Array being returned by a core method. Switching to a more permissive Iterable return type would allow implementations to return an immutable List instead, but existing code would need a way to opt‑out.

Decision:

• Documentation will start using Iterable.
• Changes to the spec tests will be guarded by a language‑level bump.
• The issue was therefore noted.

5. The next meeting (moved)

The meeting was scheduled to continue after the hour, but the upcoming FOSDEM 2026 (and the associated Community Dinner) prevents two Steering Council members from attending.

Next meeting:

• Date & time: 7 February 2026 at 19:00 UTC (20:00 CET, 14:00 EST, 11:00 PST, 04:00 JST (18 Jan))
• Duration: 1 hour maximum
• Platform: Same Jitsi URL –

Jitsi was chosen because it works reliably with minimal hassle for the Steering Council: a modern browser, camera, and microphone are all that’s required—no additional installation.

Issues slated for the next meeting

• Separate Community Resource pages
• Function return types should also tell about the used assignment/container
• Raku Classification System
• What makes unit be too late?

Preparation

Any Raku community member is welcome to attend. If you consider yourself a community member, you’re invited—no further criteria are required.

Please:

1. Review the issues listed above before the meeting.
2. Post any comments or questions on the respective GitHub issues in advance.

The original contributors to these issues will also be notified (unless they have muted themselves from these issues). We hope that they will be able to attend as well.

Small steps

If you consider yourself a Raku Community member, please try to attend! Doing so will let you put faces to the names you may already be familiar with.

Hope to see you there!