I really think the Wiki needs some tweaking. How about something like this (it is a slightly modified version of the Beagle mod of monobook)
I think we should also divert more efforts to organizing the wiki and making it easier to fond/post/understand.
I really think the Wiki needs some tweaking. How about something like this (it is a slightly modified version of the Beagle mod of monobook)I think we should also divert more efforts to organizing the wiki and making it easier to fond/post/understand.
My only question: where did you get your rather large HAIKU logo image? - I haven’t been able to find one with the "shiny leaves" - only the SVG version.
I really think the Wiki needs some tweaking. How about something like this (it is a slightly modified version of the Beagle mod of monobook)I think we should also divert more efforts to organizing the wiki and making it easier to fond/post/understand.
this looks really good, and i think someone with a little bit of knowledge about wikis should adapt this asap.
It is already adapted. I download a stock mediawiki, installed it, and tweaked the skin a bit. I don’t know if there is a project that is responsible for maintaining the wiki, but I would like to join.
AFAIK there’s nothing official in the content side and I have no idea what the go is with the maintainance side, tried getting in contact with someone a while back to no avail. Kurtis or Michael would be your best bet I guess. Keep in mind that it’s a 1.3.x release of media wiki so some things could be substantially different.
Well, if its a 1.3 release, another reason for someone to maintain it
mphipps is already working on a new website, but I still really love that look.
I was talking about for the wiki. As far a a new website, I have 2 or 3 concepts I have done for that too. I realize that that wiki skin is less "traditional" but it is more refined, friendly, and it is just as easy to use. Also, I think the wiki needs to be attractive to get users to use it.
Well, if its a 1.3 release, another reason for someone to maintain it
mphipps is already working on a new website, but I still really love that look.
"] I love it! Might ask for a few tweaks though - underline links, this is a must for colour blind users; and adjust the font (thats Trebuchet MS?) and size, because emphasized writing isn't as obvious as it should be, see 'unstable'ar1000 wrote:We really need an active maintainer, this current revision of MediaWiki bites.Well, if its a 1.3 release, another reason for someone to maintain itDarkWyrm wrote:Not that I don't believe you :wink: , but are you sure?mphipps is already working on a new website, but I still really love that look.
Yeah, I have already thought about more tweaks. As far as fonts and some of the text coloring especially. I would def. volunteer to maintain the wiki if no one is presently.
mphipps is already working on a new website, but I still really love that look.
Actually, we want to use RailFrog. Any Rails developers here that would like to help with getting it into a usable shape?
The plan is to replace both the website and the wiki with RailFrog. We are currently using the wiki to create content for the new website. But an updated wiki would be really nice because of the SPAM problems we had. I even suggested to use Semantic MediaWiki for our website if RailFrog isn’t good enough.
I think mediawiki is a good idea, albeit with modifications for access to content. Novell’s OpenSource projects all use media-wiki and 1. Look great 2. Are fast 3. Have boatloads of information. And, there is no question as to whether it is good enough for production use (example: wikipedia)
http://www.mono-project.com/Main_Page
http://www.hula-project.org/Hula_Project
I haven’t worked with Rails on commercial projects, but I have done a few private ones. I have a pretty good grasp of Rails and think I could atleast do some of the gruntwork. I haven’t worked with RailFrog, but picking up a RoR project is usually pretty straightforward. I am not sure who to talk to about this? In case someone wants to contact me I’ve given som contact information below…
mail: jonas.nicklas(at)gmail.com
msn: jonasnicklas(at)hotmail.com
skype: jnicklas
The RailFrog wiki is here:
https://secure.cvsdude.org/trac/railfrog/cms/wiki
Join the mailing list and post a “I want to help” mail with an introduction of your skills, experience, etc., whatever you find useful.
It would be nice to have a few more developers on their front (only if you’re not a potential Haiku developer, of course ;).
The plan is to replace both the website and the wiki with RailFrog. We are currently using the wiki to create content for the new website. But an updated wiki would be really nice because of the SPAM problems we had. I even suggested to use Semantic MediaWiki for our website if RailFrog isn't good enough.
I would love to see MediaWiki or Trac win the chance for the new website; we’ve already shown the wiki is useful enough because in the last week or two it has really become populated; I think the winning argument for Trac is the integrated tickets/svn/roadmap/wiki system it has… if only someone wrote some RPyC/pysvn interface thingy (I’ve never looked into python myself…) 
"]wkornew wrote:The plan is to replace both the website and the wiki with RailFrog. We are currently using the wiki to create content for the new website. But an updated wiki would be really nice because of the SPAM problems we had. I even suggested to use Semantic MediaWiki for our website if RailFrog isn't good enough.I would love to see MediaWiki or Trac win the chance for the new website; we’ve already shown the wiki is useful enough because in the last week or two it has really become populated; I think the winning argument for Trac is the integrated tickets/svn/roadmap/wiki system it has… if only someone wrote some RPyC/pysvn interface thingy (I’ve never looked into python myself…)
Unfortunately, it’s not that simple. We need ACLs, a blog, and maybe we want to translate our website into other languages. A wiki is not very powerful and its content is very static. It’s not very easy to use (we want WYSIWYG). There are no powerful templates/layouts. We would have problems uploading BeBook and other material. We prefer a real CMS. The original MediaWiki does not even allow to automate blog creation. Only Semantic MediaWiki has a query feature. And IMHO, that’s still not enough for a good solution.
Unfortunately, it's not that simple. We need ACLs, a blog, and maybe we want to translate our website into other languages. A wiki is not very powerful and its content is very static. It's not very easy to use (we want WYSIWYG). There are no powerful templates/layouts. We would have problems uploading BeBook and other material. We prefer a real CMS. The original MediaWiki does not even allow to automate blog creation. Only Semantic MediaWiki has a query feature. And IMHO, that's still not enough for a good solution.
Ultimately, it is. I agree with you about wanting more access control than MediaWiki initially gives you; But there are still config changes to keep it user-edit only, protected pages, etc. It already supports multi languages for the interfaces, and with interwiki links, controlling multiple language versions of the site should be easy.
A blog system, imho, isn’t that important, most of the devs have external blogspot accounts anyhow… and it can be done via a Wiki; I don’t believe that a few developers can’t learn basic Wiki syntax for this. Even then, a template for blogs can be provided via the… templates 
(cite tic’s SWIG site, with blog entries)
The BeBook is an awkward scenario: we can not use the current version because of copyrights, and the HaikuBook is neither complete, nor very friendly. It’s also generated via docbook from the repo, so then we have a sync. problem aswell between the site and repo, if it was written in the cms, they’d be more hands to edit it; An alternative would be to subdomain the content outside of the wiki, docs.haiku-os.org/haikubook/ being one solution.
If you’d like a real CMS, how about WordPress or plone?
Just my humble 2p
We tried nearly every CMS out there (except for JSP-based ones). They are too complicated. Plone seemed OK, but it’s a huge monster and when I recently gave it another try I found the interface too overloaded, so we’d have to rewrite the whole interface.
But the blog thing: we don’t want to have all those blogs spread over the net (DarkWyrm, Axel, Marcus, Sikosis/Phil, etc.). They must be centralized on our website. Too many people are disappointed about the lack of progress on our website. You have to dive into the community to see what is happening. This will change. Our new website must be better than anything before. It must be very professional. We want to attract commercial donors and we want to collaborate with commercial projects. We need a platform that is powerful enough. Wikis are not as flexible as a CMS. Of course, you can create a blog-like something, but it won’t work the way we want. The intro page should be more dynamic, showing recently closed bugs, SVN activity (LoC graph), and a blog that replaces our newsletter and the news items. Everything should be automated. We don’t want to manually manage everything like in a wiki.
Our dream is to have a community CMS where everyone can get an account (like in a wiki). Everyone should be able to contribute (like in a wiki), but any changes must be approved by the moderators before they go public. Yes, Plone does this, but I prefer having a separated frontend and backend because people should stay logged in when browsing our website and still not be annoyed by extra buttons (here, Plone is too overloaded).
I think the winning argument for Trac is the integrated tickets/svn/roadmap/wiki system it has
Rails has its own Trac clone, called Collaboa. It does pretty much the same, though afaik not quite as well.
Quote:I think the winning argument for Trac is the integrated tickets/svn/roadmap/wiki system it hasRails has its own Trac clone, called Collaboa. It does pretty much the same, though afaik not quite as well.
Yeah, I wanted to adapt it to our needs, but in the end it seemed to be more work than Trac (esp. since Charlie and Mikael offered to help). BTW, if someone here is a Python developer and would like to adapt Trac for us feel free to contact us on the haiku-web mailing list. Well, Collaboa would work, too, but you’d have to coordinate that with Charlie and Mikael. The requirements are listed on our wiki’s team page.
