[wiki]: Bringing FIRSTwiki back

[virtuald]

It still needs a lot of work, but I think I've got a framework in place that will make it easy to add new content. With your help, we can restore some of the original content and ensure that FIRSTwiki will exist for another generation of FIRST.

More details later, but for now: http://firstwiki.github.io/

[cbale2000]

I guess my only two concerns are...

1. The difference in layout (the main reason using "wikis" is so popular is they share a common layout that's easy to understand and use).
2. The difference in back-end code (Wikis are easy to edit because you can go out and find example code for just about anything you'd want to do).

Despite being one of the editors of the original FIRSTwiki, I'm personally not familiar enough with GitHub editing to be able to contribute in any meaningful way at this point. If you want more help from editors like me, you need to work on two major things: Page templates (basically blank pages with the layout structure there, to allow for "fill in the blank" use) and example pages (a few pages of each type that are all, or mostly, filled in, so editors know what completed pages should look like).

Also, I'd be curious if Brandon made a backup of the original FIRSTwiki before taking it down, getting a copy of it from him could drastically speed up adding content to the site and help fill in details from more distant history that many of us either weren't around for, or don't remember well.

[virtuald]

Originally Posted by cbale2000

The difference in layout (the main reason using "wikis" is so popular is they share a common layout that's easy to understand and use).

I agree, making it more wiki-like would be good. However, it is what it is now because I wanted to get it thrown together quickly. I'm definitely open to visual design changes, it's not very good right now.

The difference in back-end code (Wikis are easy to edit because you can go out and find example code for just about anything you'd want to do).

The good news is, there's a lot of information about editing markdown pages and working with Jekyll. And it's not too bad once you use it. But that feeds into your next point...

Despite being one of the editors of the original FIRSTwiki, I'm personally not familiar enough with GitHub editing to be able to contribute in any meaningful way at this point. If you want more help from editors like me, you need to work on two major things: Page templates (basically blank pages with the layout structure there, to allow for "fill in the blank" use) and example pages (a few pages of each type that are all, or mostly, filled in, so editors know what completed pages should look like).

The feedback I'm reading from you is that "we need a step-by-step guide for non-programmers to be able to contribute". And I 100% agree. It's not what people who haven't used github are used to, and will take a small bit of education to get there. But it's doable. Hopefully we can do that soon.

To more directly answer your embedded question (and I'll try to add this to a page somewhere), consider the 'mascots' page on the wiki:

• The mascots page (rendered web page)
• The mascot page (source file that users would edit)

As you can see, the source file is super simple, just like a wiki.

If you wanted to edit the page, here's what you would need to do (presuming you have a github account):

• Go to the HTML version of the page
• On the top right of the page, click the 'edit on github' button
• Follow github's instructions to edit a page
• Done!

Editing the metadata on a team's page is similar, but there's different formatting. Yet another howto guide that needs to be created...

I have some ideas for having an online editor integrated with github's API so you don't have to know how to use github to edit... but that's more involved and will have to come later.

Also, I'd be curious if Brandon made a backup of the original FIRSTwiki before taking it down, getting a copy of it from him could drastically speed up adding content to the site and help fill in details from more distant history that many of us either weren't around for, or don't remember well.

I contacted Brandon, and he was not able to find a backup. However, the copy that Archive.org has seems to be reasonably complete, and all the content I scraped from that is in the original_archive repo.

[logank013]

I remember seeing this a while ago and just thought of it again. Why does nobody try to bring back FIRST wiki? How hard would it be to add in a security measure like using captcha for each post or requiring people to log into Chief Delphi before posting? Thanks.

[Michael Hill]

My suggestion...just go with MediaWiki. It's what everyone knows and loves about wikis, and it can be extended to interface with CD if you're clever enough (and work with admins)

[frcguy]

Originally Posted by Michael Hill

My suggestion...just go with MediaWiki. It's what everyone knows and loves about wikis, and it can be extended to interface with CD if you're clever enough (and work with admins)

+1. I like your current Github solution, but I like MediaWiki even more. It has great customization features and IMO is significantly easier to use than any other wiki software.

[virtuald]

While I agree that a mediawiki solution is ideal because it's built to be a wiki, there are a significant number of issues with a mediawiki solution:

• Requires a server to host it on ($$$)
• Requires one or more people to maintain the server (time + commitment)
• Ideally, requires a domain name ($$$)
• Someone has to keep out the spammers, maintain the quality of content (even ChiefDelphi has spammers, and it is a non-zero amount of work to keep them out)
• Still have to reconstruct the content, Brandon lost the backups
• And finally, nobody has actually done it yet

If you can solve all of those problems, then a FIRSTwiki can use a mediawiki solution. However, the history of the prior FIRSTwiki shows that this is easier said than done, otherwise it would still exist today.

For the constraints that we have, github pages works great:

• No server required
• Zero server maintenance
• Free subdomain
• Github takes care of spammers for us
• I've already done a lot of the initial hard work

Finally, one big advantage is because the content is stored in git, anyone can fork and rehost FIRSTwiki if they so desire.

I'm firmly convinced that with a little bit of web design and javascript magic, the ease of use problems can be overcome with a github pages based wiki (after all, github provides APIs to allow content editing, just need something to write to those). It would take some work, but CMS solutions like prose.io show it can be done (though, prose.io isn't a good fit for us). I won't be able to get to it for awhile, but perhaps a motivated web developer can do it.

[Bkeeneykid]

I just attempted to create my first wiki document, and mediawiki would make life much easier on many levels. I am not a experienced Github Guru, but I'm certainly decent with a computer. Your documentation for contributing could use some work, but that's probably because it appears I'm the first one to actually attempt to contribute.

I went ahead and installed my Github Desktop client, because I didn't want to deal with any terminal crap. Using textedit and a Markdown style guide, I was able to write up two paragraphs and insert a picture on the PDP, and also tried to get rid of instances of the old PDB. I realize when I go to commit that I didn't fork, and just changed the base branch. Using media-wiki would be much easier, but we might not have to buy our own hosting. Many teams (including my own), have web hosting much too overkill for our little needs. We can create a separate website there, and until you've gotten enough attention to warrant a larger plan, or even your own.

We've only used a measly 750 MB of our allocated 5 GB shared storage, which should be plenty for the starting wiki. If you're interested, I would love to help you out on this. This solves quite a lot of the problems you had with a mediawiki solution. We've already paying for the service as a team, and already maintaining our portion of it, which doesn't require much more to maintain another subdomain of it. We can just make you a subdomain, such as firstwiki.nwcougarrobotics.com , which I can set up for you in just a few hours. there are Captcha systems we can enable, or perhaps even trying to integrate a ChiefDelphi login scheme. Yes, we still have to manually import all of the data manually, but it appears you were going to do that any way. And I'm ready at a moments notice to set this up.

[timytamy]

I don't know the complete backstory on this issue (ie have only read this thread), but I've seen Wikia (http://www.wikia.com/fandom) used in these kind of situations before. While targeted more at fictional universes etc I think it solves many of the aforementioned problems. Wikia seem to have the spam fairly under control, and are unlikely to disappear any time soon. I think the main downside is having to deal with ads, but imo a 0 cost solution that ticks all the other boxes isn't a bad start.

In fact, there are already two FIRST Wiki things on their (http://firstrc.wikia.com/wiki/FIRST_Robotics_Wiki and http://firstrobotics.wikia.com/wiki/Main_Page) would it be worth chasing up what's happening with one of these, or starting another one?

Even if Wikia seems like a bad fit, there are more than a few (https://www.mediawiki.org/wiki/Hosting_services) Mediawiki hosting services, both paid and free, that will take the brunt of the work out of the equation.

I think this is a bit of chicken before egg problem. It's hard to get people contributing to a wiki when there isn't any content to begin with, and it's hard to get content when there isn't anyone contributing. The challenge is getting contributors/content to a critical mass where it's a useful resource that's valuable enough to maintain, regardless of the platform it's built on.

@virtuald, I'd be happy to work with you or anyone else on looking at any of these options.

[kmehta]

If people are interested in using MediaWiki, as a core developer I can help out with setup and basic maintenance, but I'd like to not be the only person running it.

[virtuald]

It appears that both of those wikia wikis have less than 10 articles (and they're mostly stubs), so they're not good places to start. It's possible that wikia (in general) could be a good fit. Its also possible that one of the hosted MediaWiki providers could be a good fit. I haven't looked at any of those.

Thanks for the offer of web hosting -- but it does not solve the biggest issues that I identified: I don't want to maintain a MediaWiki installation at all nor do I think others would want to either (issues of time + commitment), nor do I want to deal with spam (captchas aren't perfect, and even CD authentication integration wouldn't solve everything), and I really like the idea of community members being able to download full git repos of the wiki (though, I know mediawiki has export capability too) so that if it goes under again then the content can still exist.

Bkeeneykid, I agree that the current situation with the github pages wiki is fairly terrible, and that a browser based solution (like MediaWiki) for editing the wiki would be ideal.

I just changed the edit button so it goes directly to the edit page on github -- their workflow forks for you automatically, allows editing in the browser, and then prompts you to make a pull request. Try it out.

Unfortunately, there isn't a good mechanism for creating new pages... and github pages is not good at images either.

It is certainly a chicken + egg problem. Hopefully I'll find some time this summer to fix the editing problems -- there seems to be a lot of activity in the space of creating CMS layered on top of github, and it shouldn't be too hard to co-opt some of these technologies that are coming out.

Perhaps the reason I'm not as interested in hosted wiki solutions is that my inner techie really likes the idea of a fully tweakable wiki site, that *anyone* can make a suggestion/edit of any content on the site, including style, layout, structure, etc without restrictions. While this is true of normal wiki platforms to some extent, it's not quite the same and not as instantaneous.

[Bkeeneykid]

Originally Posted by virtuald

It appears that both of those wikia wikis have less than 10 articles (and they're mostly stubs), so they're not good places to start. It's possible that wikia (in general) could be a good fit. Its also possible that one of the hosted MediaWiki providers could be a good fit. I haven't looked at any of those.

Thanks for the offer of web hosting -- but it does not solve the biggest issues that I identified: I don't want to maintain a MediaWiki installation at all nor do I think others would want to either (issues of time + commitment), nor do I want to deal with spam (captchas aren't perfect, and even CD authentication integration wouldn't solve everything), and I really like the idea of community members being able to download full git repos of the wiki (though, I know mediawiki has export capability too) so that if it goes under again then the content can still exist.

Bkeeneykid, I agree that the current situation with the github pages wiki is fairly terrible, and that a browser based solution (like MediaWiki) for editing the wiki would be ideal.

I just changed the edit button so it goes directly to the edit page on github -- their workflow forks for you automatically, allows editing in the browser, and then prompts you to make a pull request. Try it out.

Unfortunately, there isn't a good mechanism for creating new pages... and github pages is not good at images either.

It is certainly a chicken + egg problem. Hopefully I'll find some time this summer to fix the editing problems -- there seems to be a lot of activity in the space of creating CMS layered on top of github, and it shouldn't be too hard to co-opt some of these technologies that are coming out.

Perhaps the reason I'm not as interested in hosted wiki solutions is that my inner techie really likes the idea of a fully tweakable wiki site, that *anyone* can make a suggestion/edit of any content on the site, including style, layout, structure, etc without restrictions. While this is true of normal wiki platforms to some extent, it's not quite the same and not as instantaneous.

While I think that I could take on the responsibility of maintaining it, I probably can't, but if a group of people were responsible rather than one person, it would probably solve that problem. Correct me if I'm wrong, @kmehta, but I believe that MediaWiki by default has Git integration, offering the same level of protection you have on your current system. Export capability is fairly easy as well, but I'm not sure how many users actually want this feature.

I'm sure that the inner hacker in all of us would LOVE a hackable wiki, but the fact of the matter is we have to take a look at scale here. Why create a entire solution for a problem that has already been solved, with out needs dozens times over? MediaWiki is fully hackable if you really wish, and I'm not sure how it's less instantaneous. Even the older FIRSTWiki was hosted through MediaWiki, and I don't believe anyone complained about that. Much of the world's wikis are, and I don't see why it can't be an option for us.

On another note, I think I may have a less team-oriented hosting place available soon that's related to something in my signature.

[virtuald]

Jekyll has a new thing called jekyll-admin that allows you to edit your site using a more normal WYSIWYG interface running locally. It doesn't support subfolders in collections yet, but once it does then this will be an incremental step towards making this more usable for less technical people (though, still requires running ruby locally... but baby steps )