New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need to find a new hosting service #7

Closed
jd opened this Issue Mar 16, 2016 · 67 comments

Comments

Projects
None yet
@jd
Member

jd commented Mar 16, 2016

I'm slowly but surely closing hosting services that host the current awesome website. That'd mean moving out the static website, and the Mediawiki instance running.

There's no hard deadline yet, the soft deadline being 31st December 2016.

@psychon

This comment has been minimized.

Member

psychon commented Mar 16, 2016

So... for the web page, github pages, just as we already use for the API docs of git/master? What would happen with the domain?

I don't have a good idea for the wiki. I don't think GitHub wikis are a good replacement (and not just for the vendor lock-in reason). A similar bad idea would be Wikia. What other options are there?

Options for the wiki:

  • GitHub wiki (vendor lock-in, not the best thing feature-wise)
  • Wikia (vendor lock-in, ads)
  • A static ikiwiki instance. Editing the wiki would be done via pull requests to some awesome-wiki repo and perhaps we can setup some travis-magic to auto-build the wiki (hm, perhaps we should have similar magic for the awesome-www-repo?). That's one of the less nice ways to use ikiwiki, but it would at least work.

Do we want to keep the wiki multi-language? I'm not sure how up-to-date the translations really are. Only the ru-translation seems to be semi-up-to-date. If we want to keep this:

After looking at the current wiki a bit, I came up with another version:

  • Nuke the wiki from orbit and hope something so bad never happens again. :-( (Yes, some parts might be useful, no, most of it doesn't fall into this category)

Edit:
To-Do list:

  • Move the main web-site elsewhere (remember to also save the releases, they are not in git (currently))
  • Grab a static copy of the old bug tracker, wiki etc and push it to the gh-pages branch of some random repo (awesome-www-old?)
  • Decide on a new wiki
  • Move a sensible amount of content from the old wiki to the new one.
@jd

This comment has been minimized.

Member

jd commented Mar 16, 2016

It seems to me you can map a domain to a Github pages instance.
I don't have any good suggestion for the wiki yet.

@psychon

This comment has been minimized.

Member

psychon commented Mar 16, 2016

(We could also use ikiwiki)

Oh, I have to remember to save a "backup" of the old issue tracker!

@psychon

This comment has been minimized.

Member

psychon commented Mar 17, 2016

CC @blueyed @Elv13 Any ideas?

@psychon

This comment has been minimized.

Member

psychon commented Mar 17, 2016

I'm CC'ing random people. @actionless What do you think?

@actionless

This comment has been minimized.

Member

actionless commented Mar 17, 2016

I like the idea

A static ikiwiki instance. Editing the wiki would be done via pull requests to some awesome-wiki repo and perhaps we can setup some travis-magic to auto-build the wiki (hm, perhaps we should have similar magic for the awesome-www-repo?). That's one of the less nice ways to use ikiwiki, but it would at least work.

and deploy it to github pages.


but actually, if contributors will have to do PRs in order to edit the wiki anyway, mb it could make sense to have wiki inside apidocs, like this: http://awesomewm.github.io/apidoc/documentation/03-declarative-layout.md.html

@Elv13

This comment has been minimized.

Member

Elv13 commented Mar 17, 2016

I kind of like @actionless idea. Maybe we could use a middleground here. The GitHub wiki are not very good, but there is no vendor lock-in. They are available as git repositories. Instead of PR, we could just fetch the wiki git repo when building the doc and integrate it into the main documentation. We could then build the website around that (all/most links in the mainpage end up either on github git API doc)

@blueyed

This comment has been minimized.

Member

blueyed commented Mar 17, 2016

I like the ikiwiki idea (but have not used it myself much).
I can imagine making it harder for contributors then to get changes into the wiki though?!
OTOH that would eliminate the spam issue.. :)

@jd

This comment has been minimized.

Member

jd commented Mar 18, 2016

There's a lot of content in Mediawiki and I don't know if/how it can be migrated. Just sayin', think twice before picking a different solution. :)

@Elv13

This comment has been minimized.

Member

Elv13 commented Mar 18, 2016

75% of the content is outdated and doesn't work anymore. I think 3.4 is still the most used API (unless someone cleaned things recently)

While an HTML dump in a git repository could be useful for legacy versions users, I think cherry-picking the relevant content by hand wont be that bad. There is not that much to salvage.

@psychon

This comment has been minimized.

Member

psychon commented Mar 18, 2016

@Elv13 Oh nice, I didn't know that (and Google confirms this: http://stackoverflow.com/questions/18759738/effortless-export-from-github-wiki ). That might even make a GitHub wiki a viable option (updated my answer above). And it supports anonymous edits! (however, no idea about the spam-issue)

My migration plan from Mediawiki to $SOMETHING_ELSE would be to add a pick note at the top that we are migrating to something else and looking for help with the useful content (Mediawiki can do that, I forgot how). Then we can see if anyone actually helps. And yeah, I agree that losing most of the wiki's content wouldn't be bad.

For legacy reasons, we could get a HTML dump of the old bug database and the wiki and put it in some awesome-legacy-www repo's gh-pages branch.

Edit: Random wiki which GitHub somewhere recommends as nice/good: https://github.com/mbostock/d3/wiki

@Elv13

This comment has been minimized.

Member

Elv13 commented Mar 18, 2016

Also note that markdown support inline HTML, so we can actually copy paste while pages and drop the table of content, then be "done". It will be fugly and uneditable, but it would show. That's a start.

Then again, there is like 15 relevant widgets pages, 10 "how to integrate awesome with software_name", the FAQ and the external module list.

@actionless

This comment has been minimized.

Member

actionless commented Mar 21, 2016

i am agree with the point what the current wiki have lots of out-of-date info so that manual moving of only those articles which are actual should refresh the wiki a lot

@psychon

This comment has been minimized.

Member

psychon commented Mar 26, 2016

I left a note at https://awesomewm.org/wiki/MediaWiki:Sitenotice directing people here. Perhaps this will get us some input with some nice ideas on where to switch to.
Feel free to tell me that the notice is worded badly. :-)

@cobra2

This comment has been minimized.

cobra2 commented Mar 26, 2016

I just saw the notice. I'd think a dokuwiki, with the mediawiki syntax plugin, readonly install under nginx managed by git. Linode is my prefered host and I'm biased towards them.

This works very well for my local wiki.

@actionless

This comment has been minimized.

Member

actionless commented Mar 26, 2016

Linode

but it's a payed service while github pages are not

@elemental7

This comment has been minimized.

elemental7 commented Mar 27, 2016

I'm new to awesome, and I have been looking at various things on the wiki to help get me started. I have found the information to be very enjoyable and educational, so I would just like to say that this aspect (new user friendliness/accessibility) should be kept in mind for whatever the replacement might be. Us noobs need this kind of resource, readily available to non-experts, to help us out. Thanks for all the efforts on awesome!

@Elv13

This comment has been minimized.

Member

Elv13 commented Mar 27, 2016

@elemental7 Of course, we want to improve on this, not make it worst. What I and @actionless propose is to create a single place where you can get curated information. For now, there is the API doc (terrible in 3.5, hopefully great in 3.6), the Wiki (most content is outdated and doesn't work with Awesome major versions released during this decade) and some other places like stackoverflow and reddit.

My vision for the API doc is to integrate relevant articles directly into the interface. One of the first example would be this one:
http://awesomewm.github.io/apidoc/documentation/03-declarative-layout.md.html
and those (hopefully coming soon) https://github.com/awesomeWM/awesome/files/185708/wibox_widget_background.pdf https://github.com/awesomeWM/awesome/files/185709/awful_placement.pdf https://github.com/awesomeWM/awesome/files/189197/tile.pdf

They have the advantages of being hooked into our continuous integration and testing framework, so the examples and content (images, code, arguments names and type) are validated by a robot. This should solve the outdated examples issues we have in the wiki.

By replacing MediaWiki by a git+markdown based wiki solution, we should be able to streamline our processes into a single pipeline and generate an unified docbook.

I think most people here suggested solutions that could make this work. The big question is if we wish to have pull request for all edits. I did not use the GitHub wiki extensively, but I guess it is possible to require accounts for edits and lock some pages to user groups. This seem like enough for me. The only exceptions would be the code examples. I would still like those to have peer-review before being posted to: avoid running random code on our build system, avoid broken code and deter anti-patterns such as blocking wget/curl calls using io.popen().

@psychon

This comment has been minimized.

Member

psychon commented Mar 27, 2016

I don't think a GitHub wiki will work out. Google suggests that spammers also attack these, so we might eventually have to lock down the GitHub wiki to only a "trusted list of editors". Meh.
On Dokuwiki: That's based on PHP. It would be nice to have some static HTML to be more hosting agnostic (and since it looks like we will use gh-pages as hosting).

Edit: Random web page that I found and that uses ikiwiki: http://dnstap.info/

@uoltah

This comment has been minimized.

uoltah commented Mar 28, 2016

There is also https://readthedocs.org/, widely used by many OS communities.
Compared to Github wiki, it gives some more freedom, but still not as much as a static solution like ikiwiki.
Anyway, I like it since you can browse the docs by version.
Just giving my two cents. :)

@actionless

This comment has been minimized.

Member

actionless commented Mar 28, 2016

@SirJoose

it gives some more freedom

could you elaborate more on that?

i like versioning thing already

@aajjbb

This comment has been minimized.

Contributor

aajjbb commented Mar 28, 2016

Overall, I found @actionless idea to keep the wiki somehow inside apidocs to be a great one.

@Elv13

This comment has been minimized.

Member

Elv13 commented Mar 29, 2016

If we don't use the GitHub Wiki, then I also cast my vote for @actionless idea.

@alexander-yakushev

This comment has been minimized.

alexander-yakushev commented Apr 14, 2016

+1 for Github wiki, -1 for some static solution that requires going through pull requests to edit. The extra hassle would absolutely prevent a lot of useful contributions.

@psychon Github wiki doesn't allow anonymous changes, it requires users to be signed up and logged into Github. I'd argue that Github's account creation system is better than MediaWiki's, so that slightly solves the bot problem. Anyway, it seems that only some really high-profile repositories suffer wiki spam, so we might as well dodge the bullet.

@psychon

This comment has been minimized.

Member

psychon commented Apr 17, 2016

Some more static web site generators (I randomly came across this): https://gohugo.io/ http://jekyllrb.com/ https://middlemanapp.com/ http://nanoc.ws/

@alexander-yakushev Sorry, but I don't see that many useful contributions in the current wiki either. The list of user contributed themes might be nice, but just count the number of them that lead to 404s or only work in awesome 3.2 or .... As for GitHub wiki spam, the google results say that it does happen and you have zero options against it when it happens. I had enough "fun" with MediaWiki spam that this scares me.

@psychon

This comment has been minimized.

Member

psychon commented Apr 17, 2016

Vote this post up/down for GitHub wiki.

@psychon

This comment has been minimized.

Member

psychon commented Apr 17, 2016

Vote this post up/down for some static web site solution.

@virtualtam

This comment has been minimized.

virtualtam commented Apr 17, 2016

Hi all!
I'm a new awesome user, currently spending a fair amount of time in the current wiki ;-)

I don't think GitHub wikis are a good replacement (and not just for the vendor lock-in reason).

As a software developer/maintainer, I think GH wikis come with several (major) limitations:

  • no search feature (plus, GH wikis are not indexed by search engines)
  • no exporting, e.g. to a static site, PDF, ePub, etc., unless using 3rd-party software such as Pandoc and some dirty hacking scripting (example)

There is also https://readthedocs.org/, widely used by many OS communities.

ReadTheDocs (RTFD) mostly consists of the hosting & Git hook parts, as the underlying documentation engine is Sphinx, using an extended set of the reStructuredText (reST) markup format.

Here's what I like about the RTFD / Sphinx / reST combination:

  • RTFD: several versions of the documentation, usually one per branch and tag (configurable)
  • RTFD: easy configuration
  • Sphinx: elegant, unobstrusive themes
  • Sphinx: export to miscellaneous formats (static HTML, PDF, LaTeX, ePub)
  • reStructuredText: elegant and powerful markup; I find it way more convenient than Markdown when it comes to structuring data and linking to internal and external resources

Versioning the documentation along the software also eases tracking changes and keeping the pages up-to-date, plus you can set Continuous Integration builds to check the syntax of incoming Pull Requests (example) :)

@Elv13

This comment has been minimized.

Member

Elv13 commented Apr 17, 2016

Edit: upvote this post for using an ldoc based wiki

I vote for ldoc (a static generator already used for documentation with wiki/markdown support and macro support from cmake). It has a few advantages:

  • automagically generate links to other documentation pages (including the API) using the `` symbols
  • we already have it and have the CI support for it
  • we already use it for a few documentation manual and pages
  • it use plain or discount markdown, the most common "current" markup languages [1]
  • it's open source and less or more based on the same set of technologies Awesome use (lua)

[1] I had some issues with their discount extension support, table never show up, it is probably a bug

@actionless

This comment has been minimized.

Member

actionless commented Apr 18, 2016

Vote this post up/down for some static web site solution.

is this implying ldoc usage?

@psychon

This comment has been minimized.

Member

psychon commented May 23, 2016

I think Elv13's plan with the wiki is "move to ldoc". However, explaining something like Vicious in the docs that come shipped with awesome feels weird since it makes Vicious kind-of-official and it means that users get the wiki from long ago. Dunno where a separate repo for "wiki ldoc" could live and I'm unsure how much of a good idea it is to write a wiki in an API documentation tool.
My suggestions would be to move that into the ikiwiki webpage since we already have that anyway for the "not wiki" part of the website.

@martingabelmann

This comment has been minimized.

martingabelmann commented Jul 31, 2016

independent of the underlying software i also think there might be two different solutions to distinguish between (kind of) "official" docs and "community shares".

The second one could have wiki character containing all the useful tiny code snippets, widgets, themes etc... while the official is something like luadoc which is edited by pull requests only.

Then, there should be a workflow/framework between the two repositories that merges very popular/confident content from the community repo to the official docs and ensures that there is not too much redundance between them. Also cross references should be handeled by this (to get sure to not have broken links).

Maybe i`d join the discussion to late but i also want to throw in my two bits to the "outdated" content: Even if some of the old articles are outdated they still can be useful (at least for me) e.g. to just get the idea.
I like the idea to have an "archive" of the wiki which is just a html dump of everything. It might be stimulating others to renew/improve contents from there and put them again to the new docs. This would also make the question "which articles should be abdopted?" obsolete, because its up to the community... (of course the very important/obvious articles, that would directly come into ldoc can be adopted before).
One should include a header on each page (like the actual one), with additional information (that the content might be outdated and where to find the new docs).

@gutierri

This comment has been minimized.

gutierri commented Sep 5, 2016

I tried to use the dump tool (https://github.com/WikiTeam/wikiteam), but could not because he has a "request limit"(on server wiki awesome) then generates an error 500. Then extracts the list of all pages and made an export (https://awesomewm.org/wiki/Special:Export) XML then converted(with https://github.com/philipashlock/mediawiki-to-markdown) to markdown.

I put these things here => https://github.com/gutierri/awesomewm-wiki-dump

But it seems to be pretty messy, I do not know how we can arrange it for use in a static generator.

We could go moving the content gradually, thus clearing which is no longer valid and organizing information. I do not know the best way, because of a lot of work manually, there is over 500 pages.

@jd

This comment has been minimized.

Member

jd commented Sep 6, 2016

I can provide a PostgreSQL database dump if ever needed.

@psychon

This comment has been minimized.

Member

psychon commented Sep 6, 2016

@jd A dump of the state right before the web page is shut down would be nice, but it could contain private data (mail addresses, password hashes, ...). I don't know what to do about that.

@gutierri

This comment has been minimized.

gutierri commented Sep 6, 2016

@jd wikimedia has a few tricks to dump only pages (at least I think). It would be nice to have a dump it.

But before we start to work we need to define where we will put the new wiki? It seems that many people vote in some static technology.

My proposal for this is the sphinx, for a few reasons:

  • Simple
  • Many people use (thus the support is simple)
  • Documents RST(type)
  • Search
  • Extensions
  • Stable tool

And with travis-CI you can automate deploys

@Incognito4nonymous

This comment has been minimized.

Incognito4nonymous commented Sep 18, 2016

I do not recommend wikia as an option, I won't expain this since it is already well done here :
http://awa.shoutwiki.com/wiki/Anti-Wikia_Alliance

@smonff

This comment has been minimized.

smonff commented Sep 28, 2016

Why keeping a Mediawiki instance don't seem to be considered as an option?

@pierreozoux

This comment has been minimized.

pierreozoux commented Oct 24, 2016

Hey, I can offer MediaWiki hosting if necessary (and whatever hosting the community would need).
Just let me know.
(For your information, I run the following service: https://indiehosters.net )

@fjfalcon

This comment has been minimized.

fjfalcon commented Nov 20, 2016

If you need hosting service i can purchase hetzner hosting for you and pay for it.

@gutierri

This comment has been minimized.

gutierri commented Nov 20, 2016

The problem is to extract the current data in a doc with host github. Leaving all of this here on GitHub would be the best option.

I did the current Wiki extraction, but it's not what we want. My suggestion is to keep the backup in a repository and go feed to a new repository around here.

What do you think?

Using Sphinx or other tool... and using travis-ci for update web page WIKI.

(cc: @jd @blueyed @Elv13 )

@tdotu

This comment has been minimized.

tdotu commented Nov 27, 2016

If you need a server as mirror, host or something, I'm operating a Big virtualisation host in a local datacenter. You can have a VM for free. If you need a admin I'd be glad to help.
Best regards
tdotu

@jd

This comment has been minimized.

Member

jd commented Nov 27, 2016

The deadline is approaching, and the server is really getting close at the end of the year.

@Lawful-Lazy

This comment has been minimized.

Lawful-Lazy commented Dec 17, 2016

The deadline came; the wiki is now unreachable.

@Elv13

This comment has been minimized.

Member

Elv13 commented Dec 17, 2016

Yes, as of a few hours ago, we switched to the new website completely. I guess you could still access the wiki using the IP address for a few days, but archives.org has its copy here:

https://web-beta.archive.org/web/20160701200046/https://awesome.naquadah.org/wiki/Main_Page

One more reason to start porting the few relevant content to the new documentation:

https://awesomewm.org/apidoc/

@heliogabalo

This comment has been minimized.

heliogabalo commented Dec 23, 2016

hi,
I will be glad to contribute in any kind. I have a web for Linux custom_doc and that... TerritorioLinux i can place this wiki on there, if you wish.
I'm spanish, so write on english -but idea, i guess...- But i can do someThing on translating pages . I work on md's and parse it to html after.

@Elv13

This comment has been minimized.

Member

Elv13 commented Dec 23, 2016

@heliogabalo Thanks for your offer, but we already have hosting for the new documentation, we need content and helping hands to review/port it to the new system. This is much harder to get ;)

@heliogabalo

This comment has been minimized.

heliogabalo commented Dec 23, 2016

You welcome. For now i'm focused on learning gtk/xcb and othe awesome stuff, so on that way, i think you will help me more, that what can i do 4u.

@rektide

This comment has been minimized.

rektide commented Jan 8, 2017

I do think having an accessible old archive wiki would be a good thing.

What happened to the wiki was raised on Reddit recently. Not sure what the user was looking for.

I myself asked about a guake alternative and IRC mentioned Scratchdrop. A google search turned up awesome-scratch but it's link into the wiki is now dead. The wiki has the writeups for it and a link to the original repo. A way to go see that would be good.

There's 1395 pages in the old wiki. I'm all for moving forward and making docs good, but the wiki is worth doing some hacking on.

@blueyed

This comment has been minimized.

Member

blueyed commented Jan 8, 2017

@rektide
https://awesomewm.org/community/ has an "Old wiki" section.

http://awesome.naquadah.org/wiki/Scratchpad_manager redirects to https://awesomewm.org/apidoc/?redirected_from_wiki=1 (note the redirected_from_wiki=1there, which means it's recognized).

We could change redirects like that to something more meaningful (although the number of free redirects (3) on CloudFlare is already being used).

There's 1395 pages in the old wiki.

From what I've heard most of it is outdated etc.

the wiki is worth doing some hacking on.

Certainly..
but given its outdated state etc, it's probably best to move it into a new format as need arises.

I don't think a ldoc based solution is good after all / for this, but at least it knows about Markdown.. ;)

@rektide rektide referenced this issue Jan 8, 2017

Merged

Start a README. #2

@rektide

This comment has been minimized.

rektide commented Jan 8, 2017

@blueyed the "old wiki" section says:

The old wiki has been shut down, but can be still viewed at archive.org."

That is far from usable. There's no afaict searchability of the old wiki, and that's really bad.

From what I've heard most of it is outdated etc.

Except when it's not. And even if it's outdated, I'm in no rush to blast away all history. I appreciate that you are chiming in to recap the state of affairs (in a somewhat indirect way, but just telling me to go to the Old wiki section, as if it had a complete and working answer), and yes this information isn't all gone, but the Awesome wiki is going to be a very important archive of info for a long time, whether we like it or not and whether we do anything about it or not. I'd like for it's importance and legacy not to be frustration and aggravation for those who follows, and the partial usability of the current "Old wiki" answer will- I feel- certainly result in that. Let's get the old wiki to no longer be terrible.

It's easy to blast the wiki, with it's 'outdated' info, & had definitely grown into a beast, beyond being "merely" painful to maintain (spam). However I really really really am very sad there's not a place to spitball and put stuff on paper for Awesome. Nothing else is nearly as conversational yet captured. Reddit feels too much like writing a blurb or blog post on something, and doesn't link well at all. Stack Overflow is only for questions. I really think awesomewm should bring back a wiki. No place else let's people garden together. Even if that information is all caveat emptor, it was glorious and good and a super important vital piece of #awesomewm legacy.

@blueyed

This comment has been minimized.

Member

blueyed commented Jan 8, 2017

What about using GitHub's wiki then?

I hope you agree that it's better to start anew (and transform old contents)?!

@aajjbb

This comment has been minimized.

Contributor

aajjbb commented Jan 9, 2017

As the current awesome site is hosted in GitHub and it's been going through a renew, I thought about creating a new section on the site to keep recipes and important stuff from awesome (configs/modules/tips and tricks), somehow like the old wiki, but way more easier to maintain (add new stuff from pull requests).

Of course a lot of things from the old wiki are still useful (xrandr script to deal with multiple monitors, for example). Any kind of help to filter important/non-important stuff from the old wiki would be appreciated.

@aajjbb

This comment has been minimized.

Contributor

aajjbb commented Jan 9, 2017

I'm not able to reach the old wiki through archive.org. Is the a copy besides this one ?

@psychon

This comment has been minimized.

Member

psychon commented Jan 9, 2017

I'm not able to reach the old wiki through archive.org. Is the a copy besides this one ?

https://github.com/awesomeWM/awesome-www-backup-old

@rektide Itis even searchable: https://github.com/awesomeWM/awesome-www-backup-old/search?utf8=%E2%9C%93&q=foo

@aajjbb

This comment has been minimized.

Contributor

aajjbb commented Jan 20, 2017

To the ones who miss/missed the old wiki, the recipes section has just been merged to the site.

As the old wiki data is still available, any effort on bringing up useful content from the old wiki and pulling it to the new site will be appreciated.

@blueyed

This comment has been minimized.

Member

blueyed commented Jan 20, 2017

Link for the lazy: https://awesomewm.org/recipes/.
Thanks, @aajjbb !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment