[haiku-web] Re: Website

charlie@xxxxxxxxxxxxxx:
>
> [wiki stuff snipped]
>
> Go for Best of Breed assuming you can do the plumbing.
> 
It's the plumbing I'm worried about. ClearSilver.. *shiver*  But yes, 
some initial time in the beginning will probably prove valuable later 
on when there is a good CMS in place.

> 
> > I believe WYSIWYG to be overrated. Have a look at reStructuredText. 
> > A
> > quick introduction is at 
> > http://docutils.sourceforge.net/docs/user/rst/quickstart.html
> > with the actual source at 
> > http://docutils.sourceforge.net/docs/user/rst/quickstart.txt
> > 
> > Incidently, Trac supports reST syntax directly in the Wiki...
> 
> While StructuredText is pretty much all you need for this kind of 
> content 
> production having a WYSIWYG editor which generates it will definitely 
> be 
> met with approval by many users.
>
Ah, clever. I'm way too used to do all work in Vim over a SSH 
connection to care about fancy WYSIWYG tools.  Yes, I agree on having a 
easy-to-use editor generating easy-to-manage text -- we should 
definitely go for some kind of "markdown" language, instead of HTML for 
content. Wiki syntax is "ok", but it's a bit too verbose for my taste. 
On the other hand, just settling for any format will probably be good 
enough. Just worried people will be put off creating documents if it's 
too complicated.
  
>  
> > So, complicated as in a bad data model, or complicated as in 
> > cluttered
> > UI? Because the later could be modified..
> 
> Presumably they were too ambitious. A lot is expected of a CMS 
> nowadays but 
> not necessarily usability.
>
How does Plone do in that respect? The CPS install at the EuroPython2k5 
web site was *awful*. I don't know if it's the default/supposed 
behaviour, but adding a section to the page required about three or 
four clicks and page reloads.
 
> 
> > > I'm mailing to the admin list, too. So, is Trac okay for you all?
> > > We'll
> > > adjust it a little bit, though (remove a few fields, simplify 
> > > here
> > > and
> > > there, add component tree support, ...).
> > >
> > I believe Trac is a viable alternative to Bugzilla, however we must 
> > see
> > how much of it we can re-use, or it will more-or-less be a fancier
> > Bugzilla w/ ViewCVS integrated.
> 
> With the current ratio of users to developers an issue tracker isn't 
> that 
> high a priority anyway but I do expect a few ahhs if svn integration 
> is 
> possible. And anything is better than Bugzilla - bit masks have no 
> place in 
> relational models!  
> 
Bah, don't underestimate the power of enums! (I agree)

Yes, the ability to close tickets in commit messages and see them in 
the timeline, as well as seeing the milestones slowly getting filled 
with green boosts morale. (at least for me)
  
>
> > That poses a problem with Trac and its Timeline and Browser 
> > features.
> > Don't know how bad the penalty would be if the requests would be 
> > done
> > over HTTP, or if we could place a trigger on the BerlioOS tree to
> > trigger a svn up in the Haiku tree at the Trac server install so it
> > would act on a local copy.
> 
> Punish non-developers by not giving them access to these features.
>
Okay, so this is actually a real problem. Internally, Trac opens up the 
Subversion repository top folder to gain access to the commit messages 
to use in its timeline. It's also used for the source browser.  I don't 
know how easy it would be to run Trac on a server that doesn't have 
"physical" access to the repository.

>
> (In case 
> you haven't noticed the recent non-discussions on the main openbeos 
> list 
> annoyed me somewhat).
> 
What's wrong with leaf discussions? I can talk for hours on end about 
the color of autumn...

>
> Bedtime, cycling tomorrow!
> 
Woo, luxury!  Watch out so you don't fall, again!

-- Mikael
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Any sufficiently complicated C or Fortran program
 contains an ad hoc informally-specified bug-ridden
 slow implementation of half of Common Lisp."      -- Philip Greenspun

Other related posts: