I’ve had a look at what is possible without too much fuzz:
change the logo of the Python wiki to include the word “wiki” and have it point to the FrontPage of the wiki instead of back to the python.org website
add a single line header introducing the wiki and also pointing to the FrontPage for instructions.
add some minimal CSS to improve the mobile readability of the wiki (similar to what Simon suggested in the mobile thread)
Since the moin wiki software does not use templating for rendering the pages, more involved changes are not easily possible without forking the code base.
Regarding the tech itself: Yes, it’s definitely old and cranky in a few places, but it’s been running mostly fine for many many years, so it’s not necessarily something which requires an urgent change.
One way to improve the tech would be to move to a different wiki engine and migrate the content over.
I’m not aware of any other Python based wiki solution, but there are a few PHP based wikis which may work. Just a word of warning: the wiki has 3000+ pages and 30k+ users, so scalability certainly is one of the factors which would need to be take into account. Each page typically has a number of revisions (the wiki works much like a git repo), so there’s also a ton of history information which would need to be ported.
The alternative would be to have the PSF issue a grant to the MoinMoin2 team to speed up getting it into shape to host the Python wiki. The project is still ongoing, but only very slowly… https://liberapay.com/MoinMoin
I think the default theme is not mobile friendly.
(Apache Bloodhound was a fork of Python 2 Trac with a (more) mobile friendly theme I think, but it’s mostly retired I think.)
Development of Trac itself has also slowed down significantly in recent years, but there is still recent activity and posts on the mailing lists.
(Just FYI. I have no opinion on if this would be meaningful.)
An alternative to finding/updating a suitable Python-based wiki would to use a static website generator (e.g. mkdocs or lektor) and let people make edits via GitHub or similar.
Pro is that a static site is extremely scalable in terms of visitors. A con is that it’s less responsive to rapid edits, and administering a repo might be more work than the current wiki (I don’t know how much time is spent editing contributions).
Also, porting the edit history of a wiki into a git repository doesn’t sound fun…
I primary know Trac as an issue tracker rather than a wiki, and development and usage doesn’t seem to be in all that much of a better place than MoinMoin; they themselves only just released the long-awaited Trac 1.6 with Python 3(.5) support a few months ago.
Or equally so Sphinx, for that matter…oh wait, that would just be the Python docs
Static site generators are not generally set up to provide wiki-like functionality, at least without substantial custom work
There’s no real migration path for the existing wiki pages and users
Requiring going through a whole GitHub based contribution process subverts the whole reason (simplicity and ease/speed of contribution) for having a wiki in the first place, versus just having the docs (in fact, the very word “wiki” itself means “quick”, which contributing to this would not be)
Yes, almost everyone has seen Wikipedia, but it is managed very differently from most other wikis. It is actively edited for correctness and style by a large community of energetic volunteers, and there are discussion pages to see behind the scenes. The Python wiki is a classic wiki: occasionally edited with no oversight, and many out of date pages.
Wikipedia is such an outlier that it makes it even harder for people to understand what they are looking at. The Python wiki is not a Python wikipedia.
Trac has multiple modules (the first sentence on the website is “Trac is an enhanced wiki and issue tracking system…”) and any module can independently be enabled or disabled. You are right that it has been known mainly for the issue tracker module.
Yes, as mentioned activity has slowed down significantly, but at least it has transitioned to Python 3.
Trac Users: django, FFmpeg, NGINX, WordPress, JOSM, Haiku, … still seems to use active Trac instances, but for sure usage decreased a lot as “everybody” uses GitHub instead now.
It is not unmaintained, but it’s not actively being worked on anymore. In case of security issues, we can still get support from the moin maintainers (just as we did back when the wiki had an issue and the PSF provided a grant to get it fixed).
There weren’t that many reports for issues in the last few years and all have been addressed.
Trac is not really designed for larger wikis, since it’s mainly ticketing system. I don’t think it would scale to 30k users. It also lacks the advanced permission management moin implements (and we use for the Python wiki).
Those tools typically use git for adding / modifying content. Wikis don’t use a PR style workflow, so this isn’t a good match. Wikis typically allow generating diffs between edits and reverting them, but there’s no review step involved.
Gitlab does as well, but neither of those provide the permission management we’d need.
IMO, the best way forward regarding the underlying engine would be to have the PSF or one of the sponsors step in and provide funding to get moin2 into production state.
But all that is tech talk. It’s taking the discussions we’re having here in the wrong direction.
This thread started off with a suggestion to essentially start killing off the Python Wiki, even though the wiki does not even fall under the scope of the Python Documentation Editorial Board.
I found that to be a rather poor start to open up a productive discussion, so let’s reboot this and see whether we can get it on a better path.
The thread started by asking about the link in the footer of python.org. No one suggested killing the wiki, though I can see that removing the link might feel like that.
As you point out, the PDEB isn’t chartered with overseeing the wiki. I suggested putting some explanatory text on the pages to help people understand what they are looking at. Perhaps we could work together to find content in the wiki that should be promoted into the official docs (for example, TimeComplexity - Python Wiki).
As to calls for help and sprints, I’m not sure we have any larger megaphone than anyone else, and will likely have our hands full with the docs we are overseeing. We are going to be expanding and reorganizing the documentation style guide, which could be a set of written guidelines for the wiki as well, but I’m not sure the main thing the wiki needs is written guidelines.
We definitely would like to keep the discussions productive!
I’ll take your word for it. I thought Trac permissions are very flexible and can be extended via Python plugins. The examples are mainly for tickets, but wiki permissions work the same way. (But I never needed very complex permissions, so I don’t claim it’s sufficient.)
Just to clarify one point in case it contributed to any of the concern here, since Discourse doesn’t make it as clear as it should: The OP was originally mistakenly posted as a reply comment on the pinned About thread for the category; after a member flagged it, I moved it to a new thread as requested. As such, the thread title had to be my best-effort guess (which I presumed the OP would modify as desired as they should be notified of the move, thought it seems they haven’t interacted with the thread since) and not something the EB wrote themselves—I apologize if it unduly contributed to the impression people got of the OP’s intention here.
It (again) shows how difficult this “splitting off discussions to a new thread” is and reminds me of the idea to start discussing a set of guidelines for the forum.
I’ll look into implementing the changes I mentioned further up and if you like we can continue the discussions on the pydotorg-www@python.org mailing list.
Agreed; you have my full support there, and would be happy to help facilitate that development. As a mod, I ultimately want my actions (or lack thereof) to reflect the overall will of the community (and not vice versa) and a high ethical standard of transparency, accountability and fairness. Particularly when different members and different mods have varying ideas of what moderation here should look like, it benefits everyone to have a community discussion to find the rough middle ground and have a clear, consistent and public set of guidelines to follow that ultimately derive from the mean consensus of the community.
Thanks; will make sure to do in the future. I usually try to, but sometimes I forget that the comment Discourse leaves automatically (and which I typically edit to be more descriptive, as I did in this case) only goes on the original thread, while Discourse leaves almost no indication of the split on the new thread (where it mattered much more in this case). And I also wanted to include something in the title to indicate that, but we’d previously only discussed the case of renames of existing threads, so I wasn’t sure what to do. Maybe something like [Split Thread]?
