Matthew Miller wrote:
> I don't think "documentation is harder to keep up to date there" is right,

Well, I guess it does not apply that much to the pages which were already in 
an ACL-locked namespace, in particular, the packaging guidelines that can 
only be edited by FPC. I cannot speak for the FPC whether it is easier, 
harder, or the same difficulty to do the edits now vs. on the wiki.

But as far as I can tell, the move also affects wiki contents that were not 
previously ACL-locked, and for those, it makes a big difference whether 
anyone with a FAS account can just edit them on the wiki or whether one has 
to dig up the source code in some Git repository and send a pull request 
(and not get any instant feedback whether the changes even compile without 
also installing some documentation processing toolchain). I guess most 
people can only try to get someone else to do the editing work, or will just 
shrug it off as "it's wrong and I cannot edit it".

Wikis have a much lower barrier to entry than setups of the 
docs.fedoraproject.org type.

> or necessarily harder to find (although I hoped we would have a decent
> search solution by now!).

The lack of a search solution makes it very much harder to find anything on 
docs.fedoraproject.org than on the wiki.

That said, finding content on the wiki was also unnecessarily hard, but that 
was not a result of the wiki technology, but of how it was (mis)used in 
Fedora: In particular, a few years ago, the wiki's front page was redesigned 
to no longer be a table of contents for the various wiki contents, but 
instead mainly link to non-wiki content, making it much harder to find the 
actual wiki contents. You actually have to click on Subprojects / All 
Projects in the menu on the top to get something vaguely resembling a table 
of contents. In a well-structured wiki, all content must be reachable from 
the front page, only following wiki links (no menus, no search, etc.).

> But the value is in having a curated space, because the wiki serves too
> many different purposes to ever be that -- it's _always_ doomed to be a
> documentation trap.

I disagree. The wiki has become a documentation trap because most useful 
documentation was actively moved out of the wiki and because central wiki 
pages (and especially the front page) were filled with external links 
instead of wiki links. That has destroyed the entire essence of the wiki. Of 
course, if the wiki is not used as designed and if all useful content gets 
immediately transfered out as soon as it becomes useful, the wiki becomes 
redundant and the remaining documentation on it becomes undiscoverable, 
unmaintained, and useless. But the wiki is *not* "doomed" to be like that, 
it is the (ab)use made of it in Fedora that made it that way.

And I also object to the claim that that "the wiki serves too many different 
purposes" is the issue, quite the opposite: the wiki serves too *few* 
purposes now. It has become only the trashcan for anything not fitting on 
some other medium. Of course, if you treat it as a trashcan, it becomes one. 
The wiki is most useful if *all* documentation actually resides on it, and 
if as few ACL protections as possible are used. (And where ACLs are needed, 
edits by non-ACL-members should preferably be held for sighting rather than 
rejected outright. Mediawiki actually supports that: it is used, e.g., on 
the German Wikipedia.)

Having all documentation reside on the wiki would bring several advantages 
at once:
* Users would always know where to find documentation: "It's on the wiki."
  (This is actually the exact same argument that was made for moving to
  docs.fedoraproject.org. The problem is: not all documentation is actually
  there. Some is still on the wiki, some is on other fedoraproject.org
  pages, etc.)
* Developers would always know where to not only find, but also edit
  documentation, and they would be able to edit it without lots of red tape.
* The external links on the front page would automatically become internal
  links.
* The Mediawiki search functionality would automatically search all
  documentation.

        Kevin Kofler
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to