The website should be rewritten to reflect current project goals rather than Simon's goals when he wrote SILE

[ctrlcctrlv]

Since Simon doesn't work much on SILE anymore, this makes sense to me. It leads to dashed user expectations, see #1720. Split from there so as not to talk about project meta in a bug report.

[Omikhleia]

(...) reflect current project goals

Sorry to ask. What are these?

[ctrlcctrlv]

I don't know, thus the discussion! :-D

[Omikhleia]

I'm not sure whom the discussion is targeted to, but let's start simple -- I'm stating the obvious, but I'd really expect organization members and maintainers to do proper issue triage. It would help cleaning them, and have a better view of the real issues, to help focusing aims and efforts. Taking decision to close these things also shows respect to the community and gives a better image of the project, IMHO. It's a matter of good governance and vision. Here is a first list of suggestions for issues that I would really like to see closed, with the rationale.

• Answered topics

  • Setting vertical marks #318 Close (Answered) or move to Discussion Q&A and mark as answered
  • Best markup for poetry regions (Markdown→Sile) #408 Close (Answered) or move to Discussion Q&A and mark as answered
  • Braces that span lines #911 Close (Answered) or move to Discussion Q&A and mark as answered
  • Keep a group of lines together on a page #1024 Close (Answered) or move to Discussion Q&A and mark as answered
  • Google mailing list isn't publicly visible #717 (Google mailing list) Close (Fixed): Actually done...

• Obvious rejections

  • Jagpdf  #449 (JagPDF) Close (Rejected): JagPDF is unmaintained for a long time, so the core team should even not bother about it.
  • Book gutter on wrong side by default #598 (Book gutter on wrong side) Close (Rejected/Wrong): As discussed in PR 1621, this is not true. Move on...

• Sound rejections

  • API documentation #493 (API documentation) Closed (Won't fix): SILE API is not stable yet, and likely to change until 1.0. This request from 2017 came to early, and was partially addressed at the time, but I don't think the core team can devote more effort to this. Having a good User Manual is already an effort (tracked in various other issues).
  • Provide a compelling show-case document #343 (compelling show-case document) Close (Won't fix): SILE is not stable yet, and likely to change until 1.0. This request from 2016 came to early, and was partially addressed at the time, but I don't think the core team can devote more effort to this.
    Having a good User Manual is already an effort (tracked in various other issues).
  • Add image package that filters raster resources through ImageMagick #436 Closed (Rejected): It's irrelevant to introduce an ImageMagick dependency of that kind in the core distribution. The use case is very specific, but if really wanted, it could be done in a 3rd-party package (N.B. personnaly I do things of that kind in printoptions.sile and embedders.sile, and don't bother the core team with them). The core team should focus on the SILE typesetter, not on additional external tooling.
  • Draw a box around content (both inline and vertical box) #529 (box around content) Close (Rejected): The issue from 2018 has no description and the core team is not here to guess
    or make assumptions. In horizontal mode, it's already best addressed in existing 3rd-party packages with adequate use cases (e.g. framebox). In vertical mode, it's not addressed, but it could be if there was a real user need for it. Anyhow, the topic was not addressed since 2018, implying the core team has more important issues to deal with. Move on...
  • help please? want to have a box with a rule on one side #544 (box with rule on one side) Close (Duplicate): Duplicates 529, exact same consideration applies.

• Obvious "Won't fix" cases

  • Strange error about missing language #407 (Strange error) From 2017, closed and reopened multiple times without any additional useful debug, I'm not reproducing it with 0.14. The final message and status is unclear. I'd suggest: "Closed (Won't fix/Not reproduced): Not reproduced in recent versions".
  • Markdown reader doesn't handle hard breaks #416 Closed (Won't fix): Addressed in 3rd-party package. Move on...

• Questionable rejections but I don't think the core team has the capability for these issues and they start getting old. They don't really concern something that really fills a need, moreover.

  • Look into running SILE under Ravi / Luau / Pluto #725 (Ravi) Close (Rejected). Or does the core team really wants to consider this?
  • Would merging SILE.registerCommand() and \define[command]{} make sense? #866 (Lua vs. \define) Close (Rejected). Or does the core team really wants to consider this?
  • Support OpenOffice-style hyphenation patterns #277 (OpenOffice hyphenations) Close (Rejected). From 2016, never addressed... Or does the core team really wants to consider this now?

• Out-of-scope for the core team. SILE cannot afford running too many horses with a limited core team, and "Can SILE support X or Y" is an endless topic¹

  • Add TikZ support package #437 Tikz support
  • Metapost support #503 Metapost support
  • Pikchr integration #1434 Pikchr support

I have other lists of course... But let's start with these 20 issues... Can they be closed, say, by the end of March, so we can go on and resume discussion on saner grounds, on and on?

Footnotes

1. Additional considerations: First, it's best done in 3rd-party packages (e.g. I've done it in my embedders.sile for Graphviz (DOT) and Lilypond). Secondly, Tikz and Metapost are huge beasts, very tied to TeX and friends --- Don't think that people used to them will switch to SILE. It won't happen. Thirdly, let's have some pride too: It's not SILE that should support the X or Y weird graph languages. It's X or Y that should move towards SILE, if it solves something for them. ↩

[ctrlcctrlv]

@alerque I nominate @Omikhleia as getting maintainer role O_O

[alerque]

@ctrlcctrlv He's been offered the role already; I believe I asked Simon for permission to add him at the same time I asked about you or at least in that ballpart. If he's up for accepting I'd be glad to renew the invite on GitHub which has expired several times.

(And sorry I'm so far behind contributions in the last couple months, by daughter's TSC has taken a bite out of my time and energy for FOSS stuff. I'm not stopping though, just distracted.)

[Omikhleia]

@alerque

He's been offered the role already

At the time I didn't want to enable 2FA, but GitHub is now making it mandatory... It annoys me, but anyway, I set it up... Heh.
So I'll gladly accept a renewed invite. I'll have to admit the initial invite more than 1 year ago (IIRC) wasn't clear (my own misunderstanding, certainly). "Maintainer" on the other hand is a big role and I do not have half of the skills ;-)
But I'd be happy to start with at best some issue triage rights (labeling, rights to close/move/merge/rephrase issues). I'll be honest, I would really want to see the number of open issues drastically lowered, using various backlog reduction strategies.

[Omikhleia]

Also the point raised in #1720 goes beyond the web site "bragging".

In the SILE manual itself, my emphasis:

Typesetting on a grid means (....). This is virtually impossible to accomplish in TeX. There are various hacks to try to make it happen, but they’re all horrible. In SILE, you can alter the behaviour of the typesetter and write a very short add-on package to enable grid typesetting.

Which such a claim, the grid implementation has to be real robust, iron-tested, well-documented, and... used, used, used.

But in terms of core capabilities, SILE is already certainly equivalent to, if not somewhat more advanced than, TeX

(Removed after a second thought = a long list of issues... Ask me privately, because it makes the picture real bad and that's not my intent here.) ... Yet it tells people TeX is less advanced, indeed... How to expect people won't get frustrated?

(...regarding the InDesign-like frames...) so it’s possible to use SILE to generate page layouts which are more flexible and more complex than that afforded by TeX.

SILE's frame implementation is broken in many places, entangled with global variables, side effects, &c. ... so the claim is pretty wild.

And don't get me started on frames with different widths ("Pushback must die"), or absence of decent support for real multi-columns, well-balanced (#118), and a working solution for switching between several columns on the same page (see my recent experiments on Gitter).

... And that's just for the insane level of bragging found on the web site and in the manual.

As I wrote in #1720, this can only lead to users being frustrated as they realize the software doesn't deliver what it says so vividly on and on... Less bragging = Staying true about what it does (sometimes well) or where it errs.

Without trying to convince it does better than X or Y.
In other terms, as every story-teller knows: "Show, but don't tell".

[Omikhleia]

As for bragging and making not-so relevant claims and comparisons, we are obviously not alone in the shark pool...

(Source: Laurenz Mädje, Typst, A Programmable Markup Language for Typesetting, sept. 2022)

This being said, there's no reason to play that game too.

On the substance of the matter, it does tell something, though:

There's room for improving our documentation. As of Sept. 2022, it's still unclear to people (who should know better here) that the SIL TeX-Like language is not the only way to use SILE.

• The fact that it comes out-of-the-box with an alternative XML syntax is not clear...
• The fact that "inputters" can be added, meaning that SILE's core can be made (kinda) agnostic regarding the input language, is not clear (I haven't dabble yet deep into Typst, but I'd be interested in seeing how it would address native Markdown or Djot and, say, native specialized XML such as TEI).

On the "better user experience", it might be quite right, with all the spacing idiosyncrasies in the SIL language... But there's a way towards solving this peculiar point... (and there's no proof they'd do better here, anyway... The devil is in the details...)

On "tackling (with a) better styling system", it's obviously music to my ears (though of course, in late 2022, the current incarnation of the resilient styling paradigm was still a work-in-progress) 🎶 (Actually, and conversely, I am not fully sure how Typst intends to revolutionize styling and abstract it outside of both the code and the input content 😁 )

[Omikhleia]

I think most of this was addressed:

• SILE manual has been improved
• Most of the issues referred to in one of my discussions above have been closed. (Last I looked, only 3 were still open, which is decent).

After almost one year, I don't think there's much to add here -- But of course, please feel free to open new issues or discussions on specific items.