Partkeepr: Partkeepr Wiki

For now the only thing I've managed to make "work" is by using googles cached pages. You simply search for a relevant wiki page, google shows a result and then instead of clicking the link itself, click the little down arrow next to it and then click cached. It'll be unstyled but the content is there. Or go by using archive.org: http://web.archive.org/web/20180310044536/http://wiki.partkeepr.org:80/wiki/Main_Page

I do hope that at some point the wiki comes back, even if only as bare html in a folder on github (or in the wiki tab on here).

It looks like the wiki is back online.

Excellent news! Closing.

Anyways, does anyone know where the wiki is hosted? Is this still in the respponsibility of @Drachenkaetzchen? In another issue the problem of Partkeepr been a bit stuck at the moment is described. It might be a good way to help @Drachenkaetzchen and take the responsibility for it on other shoulders. Then, a backup of the Wiki/SQL is needed.

@Gasman2014 All in all I would vote to reopen until this issue is solved on the long term.

I'm with @christianlupus, I'd say host it in the githubs' wiki section instead, that should take some load off of @Drachenkaetzchen's servers and shoulders.

In view of the desirability of a longer term solution and the suggestions of @C44Supra and @christianlupus to try to support Felicia @Drachenkaetzchen by archiving this data and hosting it independently via github, I am re-opening this. The information in the wiki is very helpful to troubleshooting installations - particularly in niche situations not described within the main setup guide. This information should be available alongside the codebase for maximum usability. I am very pleased to see the wiki has been restored but perhaps it could without too much work be combined with the github wiki section which also contains some helpful but additional and different information.

If someone can provide a way to automatically move the hosted wiki to GitHub, please go ahead and let me know, but only if you actually tested such a mechanism. A simple google yields many results for such a mechanism, and I do not have time or energy to look into them.

If you need some kind of API access for the current wiki or a DB dump, please let me know.

I would be willing to try to prepare this. I will try to migrate to a wiki in my personal account. As far as I have seen it, I can only migrate the latest version of the wiki and some manual tweaks are needed.

I tried to migrate the wiki files to github. The result is visible in this repo. There are still some minor modifications needed (like removing typos, renaming pages, organizing files etc).

Unfortunately, the automatic exporting to XML (standard way to export from mediawiki) has some drawbacks. This way, the history of the pages are lost and no media files are exported. I downloaded them manually but the metadata (like the title and alt text) was not ported. Also, github's wiki is a bit more restricted than Mediawiki causing e.g. lists of subpages impossible as far as I found out.

@Drachenkaetzchen I would ask you to verify that the wiki can be used this way. Then, you can simply install the pages from my repo on the Partkeepr page if this was ok for you. Contact me in case of questions, I would be very pleased and proud to help.
PS: I added you as a collaborator to the repo so you can play around with it.

All others are welcome to look through the wiki hunting for errors I missed.

@Drachenkaetzchen I would ask you to verify that the wiki can be used this way.

I'm confused, what exactly should I verify?

I ported the wiki to github. Please check if this work is acceptable by your quality standards and I did not mess up completely.

I think you should ask the users ;) I rarely use the wiki.

I suggest to ask for feedback on the mailing list

I left a message on the mailing list. Cross-referenced here only for completion.

I suggest that we go with github Pages instead of a github wiki. We would have more options regarding file organization there and there is no big difference between the two solutions. Are there any options that a github wiki might be better suited?

@Drachenkaetzchen I did not get much attention and response from other users regarding the migration of the wiki. Do you have any schedule or how would we proceed here? I would prepare the migration in terms of making the links work and the filenames useful. As this is manual work, I'd prefer not to do it, when not used later.

I really can't give any feedback. I am only able to do bare bones admin stuff for the project.

OK, then I ask @dromer to give his opinion.

Hey all, I haven't seen any discussion about migrating the wiki to github.

I do think it makes sense to concentrate all the info we have into a single resource. But also the info we migrate over should be relevant and pruned of legacy things.

My experience with github wiki and pages is pretty much non-existent so I can't really comment there.

[edit: ah pages would be like a jekyll site or something. any preference for an autoformatter then?]

ah pages would be like a jekyll site or something.

Yop, that's pretty much it. The wiki btw as well. The difference is that pages is intended to be used for a site while the wiki for a rough set of more or less short chunks of information that are not sorted/organized. This had me (during my first test of the migration) caused some trouble as filenames are automatically guessed by the underlying server, e.g. case sensitivity caused problems.

What do you mean by you sentence

any preference for an autoformatter then?

You mean the styling/layout?

Sorry I meant the site generator. I believe github pages can use others than jekyll?

I'm not sure jekyll will be the easiest/nicest way to organize a wiki though, what would the advantage be over the github wiki exactly?

I don't think we should necessarily host the main partkeepr website just yet, lets focus on up to date information resources like the wiki.

There are some fragmented pages on the github wiki as well I think. This all should be converged with only relevant and correct information for the current state of the project.

Sorry I meant the site generator. I believe github pages can use others than jekyll?

No problem. Could be, I did not work it out completely yet.

I'm not sure jekyll will be the easiest/nicest way to organize a wiki though, what would the advantage be over the github wiki exactly?

Well, the difference is minor to be honest as far as I see it. Both take markdown (or whatever format pandoc can read) and format it in a nice way.
I found the problem, that the wiki does not allow for namespaces and the mapping between links and the corresponding file name is sort of heuristic:

• The wiki contains two pages which differ only in the case of their titles (1, 2). I had to manually remove one of these to make the heuristic select the right one.
• Subfolders (used as a sort of namespacing) can only be created when checking out using git manually. The links do not respect this namespacing thus you can only have each filename once, rendering the folder structure counter-practical. I do not know how github selects the page to be named in case two files have the same name.

One additional advantage of the github Pages solution is that you can run jekyll locally to check the appearance and all the links without publishing yet. Also I think you could do more styling (but I would have to check that out).

I don't think we should necessarily host the main partkeepr website just yet, lets focus on up to date information resources like the wiki.

No, I think this is located at the moment at a good location.
Although I might want to point out that there was (?) the idea of using github for the main homepage. If the need arises, one could migrate to github (if financial situation of Drachenkaetzchen gets worse so she has problems to pay for the server).

The whole point of this issue is to preserve the current wiki in case the servers go down.

There are some fragmented pages on the github wiki as well I think. This all should be converged with only relevant and correct information for the current state of the project.

Yes and no. It should be related to the most recent version of the software. However I think the documentation is comparably low in the project. I know we are short of manpower but without documentation the users have more problems to see how the functionality of the software works.
So I pledge to update the docs to the most recent version but keeping e.g. migration guides from older states, never the less these are for heavily outdated versions by quite some time (maybe splitting up some of the pages to make them better readable).

I am hoping we get some traction in the community (you might laugh at my optimistic thought) that help by adding hints and tricks how to set up things. During the last few days when I worked through the ancient issues, I saw quite some good ideas from community members, that might be worth mentioned in a wiki-like page.

I'm happy either way.. but having a maintainer would be a good idea... my experience is that these things age fast

That is true. You mean one person solely dedicated to keeping the documentation up-to-date?

I would be okay to help the project in this way as well. Do not understand me wrongly: I am not pressing into this position. It should be decided consensuosly.
At the moment there is not much new things to document. Mainly updating the existing one. This might change if the project gets traction again and new code is written/changed. Then the maintainer of the documentation is dependent on support by the devs in the sense that the manager is not capable to understand all the technical details.

I have a bit more energy today, so here are a few thoughts:

• The current wiki makes it hard for people to contribute documentation since I had to disable registration, requiring me to manually create users
• The GitHub integrated wiki makes navigation hard, especially if there are many pages not properly linked from the main page.
• It must be easy to contribute documentation. Preferably where users can simply click an "Edit Page" button to edit existing content, and a button to create new content. An example which I like can be found here: http://marlinfw.org/docs/configuration/configuration.html - changes will result in a pull request so it can be reviewed and properly linked by a documentation maintainer
• However, in the previous example there's no "New Page" button, not sure how this could be done

• The current wiki makes it hard for people to contribute documentation since I had to disable registration, requiring me to manually create users

That is somehow a contradiction to a wiki but I understand the needs.

• The GitHub integrated wiki makes navigation hard, especially if there are many pages not properly linked from the main page.

That is perfectly true. I do not find it very esthetic how the wiki is built. One has to make sure that there exists fine net of links throughout the wiki in order to simplify navigation.

• It must be easy to contribute documentation. Preferably where users can simply click an "Edit Page" button to edit existing content, and a button to create new content. An example which I like can be found here: http://marlinfw.org/docs/configuration/configuration.html - changes will result in a pull request so it can be reviewed and properly linked by a documentation maintainer
• However, in the previous example there's no "New Page" button, not sure how this could be done

They use the github pages feature but in a more elaborate setup than the basic one. I did not get through everything yet but I can look into things...

A user is actively collected information in a local WIKI that is shared at https://readthedocs.web.cern.ch/display/PARTK
He has offered to port this information to a different location, but guidance from the project team is requested. The thread for this can be found in the PartKeepr Google Groups https://groups.google.com/g/partkeepr-users/c/ehqapXqyY0o/m/1VWkA00dDAAJ