[haiku-web] Re: Website

Cross posting: FYI, we have a new ML for the web team:
http://www.freelists.org/list/haiku-web
Is anyone against switching to Trac for managing our tasks and bugs?

Mikael Jansson wrote:
So we really want something like a Wiki at this point, but perhaps with a bit more structure? I've used CPS once and although a bit heavy-
weight, having a document authoring system with versioning support is good to have. No point in rolling your own stuff when there are nice solutions available. The question is how much one could use from, say, Trac should we go for that - it's got a Wiki, but it's certainly not a full-blown CMS. Charlie?
and Charlie Clark wrote:
Furthermore, it's much easier to contribute than to keep up to date. Documentation is a bit like software in that respect. Even worse when it gets translated. You can't leave publically published content to the wikipedia bunch. Someone has to take responsibility for it.

The CMS should not allow everyone to publish content. It should rather
be added to a queue, so moderators can look at it and either delete or publish. I don't want the wiki approach where we have to clean up after everyone.
I definitely don't want the Trac wiki. Our CMS should do that job.

Let's clarify my wish for the website:
* usability is very important! there must not be any learning curve! our
developers probably won't care about the website very much and if they
want to publish a little text they must not have to read some
documentation to use it. it must be *highly* intuitive
* moderated: unauthorized persons propose content, moderators publish it
(e.g.: newsletter articles, btw newsletter can be replaced with a blog).
this replaces our wiki.
* WYSIWYG
* nice page tree (in backend)
* at least two independent blog/news pages (one for users, one for
developers with newsletter technical status updates, centralizing all individual blogs [Axel, Rudolph, ...])
* multi-lingual. no need to translate everything, but at least "Goals",
"Downloads", "How To Install", and the most important news. I could help
with the German translation (and I can speak+read some Russian, maybe
that can be helpful...)
* FAQ manager (one page per category or all on one page)
* mailing list with forum interface: you can subscribe to a list and use
mail or you use web interface and regularly look for new posts (and use
notification mechanism like that of phpbb)
* Trac with discussed modifications
* single-sign-on

That should be everything. I don't think we need special team pages like
on our current website.

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

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.

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.

Charlie Clark wrote:
Please sort out the organisation of teams and how bugs are to be dealt before asking for customisation. At yellowTAB we simply disabled the ability for non-developers to say or even see who was dealing with their bug.

Apart from the subscription stuff everything I had suggested in my earlier mail is still valid (in this case: users can't assign, but see who is working on it, users can only create bug reports, but not tasks, ...).

Bye,
Waldemar
-----------------------------------------------------------------------
haiku-web@xxxxxxxxxxxxx - Haiku Web & Developer Support Discussion List

Other related posts: