The old Documentation mailing list? Yes!
I am assuming you’ll add a “Use Discourse” post first before making it read-only
Hi guys,
regarding to the documentation i have a question. The “old” forum have really a lot of knowledge in it have seen the idea to save some important informations/howtos/… to the wiki. So a question arises for me, where should this place be ? Since we have a lot of different categories to potentially transfer.
Are there some ideas for this already ?
Best,
Erik
Which place for what?
To save some informations from the old Forum before it gets deleted in the wiki.
Yes, that is supposed to go on the wiki…
Hi all,
but where ? In mostly articles the “keep it short and pretty” formatting is active, i think it might not be a good idea to copy and paste the forum stuff into it. May Jon do have there also ideas ?
Best,
Erik
No, do not copy and paste a forum discussion. That is not the style of a wiki…
What you can do it extract the information from a thread and add it to an extra page or improve what is already there and answer the question that somebody had by adding another sentence.
In my opinion I strongly suggest keeping the old forum read-only for a year or two. You have a wealth of excellent information in the old forum and zero information in the new Community.
Yes the old forum has links that do not work but the bad links all include the same issues. If a user hits an old wiki link and is informed to remove the /en or the /start then it is manageable. Not ideal but manageable.
I think the biggest issue is finding users/people to determine what is worthy of migrating from the old forum to the wiki.
- determine what is worthy
- edit it for wiki use (instead of forum use)
- find a place for it on the wiki (not everything is easily placed)
- save it
You could also PDF good threads and save them in the new Community. They are searchable but they do cut off some of the code blocks. And Discourse would need PDFs enabled (right now it is disabled).
Not the best idea, but doable.
2 Likes
sure haven´t meant it in that way 
but some howto´s, projects (what is with them in general if they aren´t merged somewhere), smaller and bigger extensions/hacks ← what might be a definition for what is worth to keep it → needs some more space and to merge it into the already existing articles can bring the old order again to a kind of collapse (too long, too difficult).
Adding another page can be a subpage then ? Linked like e.g. in the proxy wiki ?
i think so, there are loads of informations in it where it was just practical to link to a already answered topic instead of explain it again. It might be a good chance now to check which questions arises repeatedly to complement them in the wiki.
See the same problem there whereby point 1. and 3. is essenttial in my opinion.
Best,
Erik
Smaller extensions and hacks should not be on the wiki. They should either be upstreamed into IPFire or not exist at all.
LOL, I am really coming across as a freaking hardliner now, but I cannot help it…
There have been loads of pages on the Wiki about how to manually fix some certificate issues for iOS, a whole IPv6 guide with binaries that were uploaded only for x86_64 and which stopped working after a short time. People take this information very seriously and very often it is not. If a page is no longer being maintained by its author I will go ahead and delete it. This boils back down to the old debate about multiple languages. It is better to have nothing on something than bad or false information about something. We need to treat the wiki as a book that we could send off to be printed at any time and where information is easily accessible and valid for as long as possible.
Yes sure. Create sub pages. I like them. Just make sure you do not add the same ones twice.
A good hierarchy is very very VERY important, because that is how people search for information. Pages should not be in some random places…
Yes, we have to start a little bit from the beginning again, but I do not expect us to be spending too much time to answer questions that have been answered before.
Yes, there is work to do now. But is the alternative to stick with the old forum and spend hours and hours on spam fighting and all the other problems that it brings with it? I think not. So we need to invest something now to gain advantages.
I spent a lot of time setting this up, building people.ipfire.org and the whole backend. It works nicely and it helps us to focus on other things now. I am proud of it and I hope that we all did well here. I am sure we did.
1 Like
If the old forum becomes read-only (and nothing new is written to it) do you really have spam issues on the old forum?
Yes you do - please work to find consensus. You’ll find more people willing to help and your workload will eventually go down.
No we won’t have those any more, but it will still be an unpatched piece of PHP garbage from hell.
Oh I am. We have had these debates for years. There is a consensus between those people who go involved in the conversation and we know that we had a couple of hard decisions to make. We won’t make everyone happy in the end, but that is again something we have decided - after long hesitation - and we are sure that it will upset a couple of people.
However this is a great opportunity to make many many things better and there won’t be too many people giving us a good pet on the shoulder in public. Unfortunately there is always the upset people opening a big debate in public.
Over the years I had so many of them. I tried to listen to those people, find solutions to their concerns. But in the end it was always all for nothing. A waste of my time. Those people will always find a reason why they cannot contribute anything any more. It was never going to stop with one concern. That is why I am now fighting for the decision that has been made and try to uphold it as good as I can.
How can I access the mailing list?
Will I get all old postings?
All of the old Documentation postings are located here:
https://lists.ipfire.org/pipermail/documentation/
For the old Development postings:
https://lists.ipfire.org/pipermail/development/
Does this help?