[haiku-web] Re: Website

Waldemar Kornewald <wkornew@xxxxxxx>:
>
> That should be everything. I don't think we need special team pages 
> like
> on our current website.
>
It might be nice to enable that feature for the future, even if not 
needed today. It's certainly possible a single piece of Haiku requires 
more space than others. Although, I suppose a tree structure would 
solve most of that.

Furthermore, there's another usability aspect of it all -- there should 
only be one way to do it, instead of many possibly overlapping 
features, which only causes confusion and makes nobody really use it 
anyway. So, let's begin with the most basic features and continue 
adding from there.
 
> Mikael Jansson wrote:
> >>> I would simply do without the  
> >>> cc: option which is simply a pain
> >> What exactly is painful about a "Subscribe"/"Unsubscribe" link 
> > > placed 
> >> at 
> >> the top of every ticket's details page?
> >>
> > Because you'll be subscribed to about a hundred bugs at the very 
> > least. 
> > Unsubscribing to them all when you don't find them interesting 
> > anymore 
> > is an extremely tedious task. Therefore I agree on RSS being the 
> > preferred way to monitor changes, be them on web sites or in a 
> > ticket 
> > system.
> 
> Okay, hopefully this is a better solution that makes everyone happy:
> * use RSS to watch for changes per ticket or all ticket changes
> * use Timeline to watch tickets
> * maybe have a mailing list
> * no subscription or Cc
> * require registration with email
> * developers can see email address of everyone, so they can send a 
> mail
> directly in case they have more questions
> 
Sounds good. There could, in addition to the Timeline and RSS feeds, be 
an announcement list either one e-mail per tickets or a daily digest (I 
don't know how it's usually done, maybe daily is the best).

>
> > So, complicated as in a bad data model, or complicated as in 
> > cluttered 
> > UI? Because the later could be modified..
> 
> I was talking about usability. Modifying the UI would require a *lot* 
> of
> work (for most CMSes) because we need too many features.
>
Hrm.. I'd say the most important thing about a CMS is its data model -- 
easier to customize a bad UI than to work around a bad data model. 
Charlie?
 
>
> > As you said, SVK might help out there.
> 
> The "svk mirror" command increases the revision of the repos, so we'd 
> be 
> off by one when mirroring. Looks like this won't work...
> It would have been nice, but I think that we can as well close bugs 
> using the web interface. Please don't spend too much time on this. It 
> can be done later, if at all...it's not very important.
>
I think a post-commit script at BerliOS triggering a "svn up" at the 
server running the web stuff should work, probably requiring some 
changes in how Trac accesses the repository (which will be a working 
copy in this case).
 

-- 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
-----------------------------------------------------------------------
haiku-web@xxxxxxxxxxxxx - Haiku Web & Developer Support Discussion List

Other related posts: