Hi!
Meta: I might have overreacted when reading "ikiwiki is crap in this
regard". As a developer, when I read this somewhere while I've never
been told anything about the actual need/problem, I'm often pissed off
because I feel I'm essentially being reproached not to have fixed
a problem I was never told about. That's not the best and most
constructive reaction of course, at this point I should ideally engage
with the people who complain and listen to them (if they're ready to
spend time explaining me why my software is crap), but I think it's
a very common and understandable way to react to such
indirect feedback.
And anyway: thank you sajolida and u for sharing!
u:
> sajolida:
>> intrigeri:
>>> sajolida:
>>> I'd be happy to help translate "ikiwiki is crap in this regard" into
>>> actionable bug reports, but I can't do it alone.
>>
>> I admit that I'm very bad at reporting bugs to ikiwiki but in my
>> imaginary at least, ikiwiki is not a very active upstream project
>> either.
It is indeed not very active but quite a few bugfixes and some new
features made their way into it:
http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=debian/changelog
>> So I thought that the bugs that I might fill would just rot
>> there forever.
> Same here.
It's definitely a possibility, as with any bug report to any free
software project whose developers work as volunteers on their spare
time. So I acknowledge we should avoid spending too much time
reporting bugs, and probably no time at all when our requests are
outside of the "faulty" software's scope & mission.
>> Now:
>>
>> - Improving our website in general, like reporting and fixing bugs in
>> ikiwiki is nowhere in our core budget so it would have to be volunteer
>> time, and at least to me, not at all exciting time. Maybe that's a
>> problem in our core budget but right now changes happen on the website
>> mostly through technical writing (which is about content), ideally
>> through UX (tiny tiny bits), as side effect of other work
>> (installation assistant, donation campaign, etc.). But right now
>> nobody is really responsible for this work I think.
In my dream world, it's part of everyone's job here (at least when
paid) to report bugs they're seriously suffering from to the authors
of the faulty software, and if there's no chance these limitations are
fixed, acknowledge we need another tool and request it (I do know
you're researching ways to escape ikiwiki, and it's great!).
I understand we don't live in that dream world i.e. there seems to be
a culture clash between free software geeks like me and other people
(e.g. whose only free software project is Tails): the disagreement
here lies between what is obvious to you vs. what is obvious to me.
I'll try to keep this in mind and avoid enforcing my worldview on this
area of the project, and on you specifically :)
>> - The limitations I suffer the most from in ikiwiki seem, at first
>> sight, too deep to deserve a bug report. The "templating" system
>> extremely primitive and my suggestion would be to replacing
>> completely, it has no CSS framework, it's not designed for content
>> reuse, etc. But I trust you intrigeri to help me frame this as
>> more pragmatic fixes that can happen before the year 2525.
Sure, I can at least help sort things between "potentially usable
feedback" and "outside of ikiwiki's scope & mission".
> What my problems with ikiwiki were while working on the donation campaign:
Thanks! I'll comment inline with suggestions wrt. the bug reporting
that you volunteered to do.
> - make it easy to add parameters to URLs when building links, i.e.
> [[linktext|path/to/link]] should be able to also build links that
> resemble [[linktext|path/to/link?param=something]] and let's go crazy:
> [[linktext|path/to/link?param=something&somethingelse]]
This looks like a valid feature request to me, although the actual
implementation suggestion cannot work (at least "?" is valid in
ikiwiki page names) so it'll require a bit more thinking from
developers wanting to satisfy our needs.
So I suggest you describe in your feature request the need (extracting
stats from web server logs), the solution you wanted to use (quoted
above) and the solution we ended up falling back to.
> - the template language can only check for boolean variables while it
> should be possible to check for a value, i.e. @if var == (string)
> value@. Currently ikiwiki can only either print variables or check if
> they are set or not. This is the part I found extremely limiting.
I concur with sajolida and you on this one. I've been severely bitten
by this when trying to build another moderately complex website with
ikiwiki years ago. For backwards compatibility our request is then
something like: "please add opt-in support for template engine X"
(assuming template engine X has Perl bindings) or "please add opt-in
support for a more powerful template engine" (describing the needs as
you did above). Don't spend too much time on it because I think it's
not cheap to implement and would bring value to very few (current)
ikiwiki users.
> - I want to be able to include template parts, or to be more precise,
> .mdwn files, within page.tmpl based on some if statement. These template
> parts should be translateable.
I *think* you're describing a mean to an end, and that mean is pretty
hard to implement without breaking ikiwiki's security model (the
template is trusted, the pages are not; this makes sense in the wiki
paradigm, but we're not using it to build a wiki).
IIRC, what you want at the end of they day is basically translatable
templates, and since templates are not translatable but pages are,
we've tried to include translatable pages into templates and then
realized it was explicitly forbidden for security reasons.
So I suggest you describe this need in your feature request :)
>> What's the next step here and who will do it? Call for a voice meeting
>> with intrigeri, u, and me? Take a few hours during a sprint to talk
>> about this? I'm at least not ready to take long hours to write emails
>> about this and would need synchronous communication.
> I can create bug reports out of these three things I guess.
> No need for a meeting from my POV.
I say let's skip the meeting and the features request that essentially
ask ikiwiki to change its paradigm in depth to be more adequate to
what we do with it, and instead spend the smallest possible amount of
time reporting more specific issues such as those u listed above.
Cheers!
--
intrigeri
