Le 5 août 07 à 16:53, David Chisnall a écrit : > On 4 Aug 2007, at 03:22, Jesse Ross wrote: > >> - The blog is using a different content management system >> (Blogger) than the rest of the site (Mediawiki), thus we're all >> maintaining two separate accounts to get content onto the site. > > This is the one that really irritates me. The Blogger interface is > absolutely terrible. The rich text editing thing doesn't work at all > (it randomly drops characters, or decides I want to overwrite > something I've already written). The HTML entry seems to mangle my > HTML in unexpected ways. It doesn't notify me of comments left on my > blog entries, so I don't reply to them punctually, and it doesn't > notify people that I've responded to them, making the comments system > useless (not to mention the lack of threading etc.) Having to > maintain a separate account for that is mildly irritating too.
Fully agreed. >> - Content management/navigation of Mediawiki is problematic (pages >> are not in well-defined parent categories, end-users have >> difficulty accessing relevant content) > > Part of this is a layout issue with our current design. We have some > navigation boxes at the top, and some on the side, and I tend to > forget about the ones at the top (they don't provide a strong visual > clue that they are navigation related). I observe this tendency too. > I also don't update things as often as I should > because MediaWiki markup is a pain to use (and very badly documented). You can find a complete markup documentation summarized here: <http:// meta.wikimedia.org/wiki/Help:Wikitext> This page was a lot easier to find previously :-/ There is also a reference card: <http:// meta.wikimedia.org/wiki/Help:Reference_card> If you don't like, you can use HTML directly instead of the wiki markup when you edit website pages. This is a feature I personally like in Mediawiki. Here is HTML markup you can embed in a Mediawiki page: <http://meta.wikimedia.org/wiki/Help:HTML_in_wikitext> > Even though it's a bit verbose, I wouldn't mind having to enter [X] > HTML, although the big problem with that is that there is no extra > indirection with URLs, so you have to be careful with them. > > The web space we have on GNA supports server side includes, so it > would be relatively easy to use this directly if we had a set of > template pages and a set of banner includes (e.g. header, footer, > sidebar). To make a new page, you'd just copy one of the templates > and link to it. This solution is the one used by GNUstep website. In the past, I made minor updates to GNUstep website with this setup. In my experience, it was really not practical at all. Making a simple update is really time consuming in this setup when you compare it to a wiki, that's why I quickly forgot about fixing GNUstep website issues I encounter :-/ It convinced me of the importance to use a wiki-like solution for Étoilé website. However it's true a wiki-only solution suffers from many problems. > I think part of the problem with the current layout is that it's very > easy with MediaWiki to create new pages, leading to a lot of sprawl. Well, you are probably right. If we add some basic rules for website editing and we appoint someone to be in charge of the website organization/navigation, it should solve the problem. >> - We need good, recent documentation in an easily searchable/ >> browsable format > > I would like every svn commit to be accompanied by an automatic make > of the documentation on the server. This would be possible with the > svn commit hooks if we ran our own svn server (which I don't > suggest), but is harder with GNA. I've filed a feature request with > GNA. Another option is to use the downloads area to host the > documentation (e.g. http://download.gna.org/etoile/etoile.html). We > can upload to this using rsync, rather than svn, which makes it a lot > easier to automate. I think putting documentation in GNA download area as suggested by Yen-Ju is the way to go. > If we added a target to etoile.make that would > set the document install directory to a temporary location, make and > install the documentation there, and then rsync it to the server, > that would probably be helpful. Sounds right. We should just take care of avoiding any upload when the documentation generation fails. We should also keep latest release documentation separated from -trunk (or -stable) documentation. >> I know most people are comfortable with Mediawiki based on >> conversations we've had before, but I'm wondering if using >> something else wouldn't be better. In the past I've proposed >> WordPress, but Drupal looks like it might be a good long-term >> solution also/instead. I'm wondering if anyone has any other >> suggestions about what to do with the site, or if there are any >> major objections to moving to something drastically different in >> the process of building 0.3. > > After 0.2, we used something like 50GB of bandwidth in three days. > Hopefully 0.3 will be even more popular, and so anything that > involves none of us having to pay for that seems like a good > solution. I would advocate putting as much of the site on GNA as > possible. Makes sense as long as it doesn't prevent easy and quick edition of web pages. > Use the website area in svn with SSI for the main pages, > and the download area for automatically-generated documentation. I'm > not sure what to suggest for the blog. I found a support item from > 2004 saying GNA planned on supporting PHP 'soon,' but as of 2007 they > still don't. They do support Apache SSI, which apparently allows the > running of external programs, but I'm not entirely sure how one would > go about using this. Without this, allowing comments is quite hard. If I don't have to resort to svn and [X]HTML editing (except for the front page and may be three or four additional pages), I'm fine with any solutions that provides a simplified markup (like wiki, ReST etc.). The best would be a solution which supports: - both a wiki-like markup and some [X]HTML subset (as Mediawiki does) - editing pages directly inside the webrowser (as Mediawiki does) and also outside of it with a text editor. >> Home etoile-project.org >> - News /news (blogs, press, feeds) > > I like these sub-categories. We should try to keep a clear > distinction between blogs (what developers are saying) and news (what > the project is saying officially). Agreed. >> - For Developers /dev -> dev.etoile-project.org >> - Getting Started dev.etoile-project.org/start >> - Installation dev.etoile-project.org/install > > These two are definitely needed. Currently we have more accurate > information on the blog than on the main site for installing. If this is the case, INSTALL document which is referenced on the website should be updated. >> - Documentation dev.etoile-project.org/docs (needs to allow for >> user comments) > > We can automatically generate PDF and HTML documentation for > frameworks, and I suggest we start doing that and putting it online > soon. Any insufficiently documented framework should be treated as a > bug for the 0.3 release. I agree, well at least for all frameworks which are here to stay and won't be deprecated anytime soon. > Two things I would say are missing: > > - FAQ. > We want a quick reference to questions like 'are you trying to clone > OS X' This should be the first one in the FAQ :-D > - People > It might just be me, but I find it easier to trust a Free Software > project if people are willing to put their names to it. Having > faceless developers makes it much harder to relate to the project. > We have something like this on the current site, but it's quite well > hidden. Agreed. However 'People' page is linked on the front page. The link is called Developers. I would be in favor of renaming it 'Team' to make its intent more obvious. Cheers, Quentin. _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
