[haiku-web] Re: Trac (was: Website)

I'm waiting for Marcus' reply. If he is open to testing it then nothing
speaks against setting up and customizing a sample Trac install that
everyone can test.

About the website structure: This was my (brief) proposal:

News (front page with very brief intro)
Goals
FAQ
Screenshots
Downloads
Development
   Getting Started
   Projects
     Kernel
     Interface
     Networking
     Media
     ...
   Documentation
   RFCs
   Blogs
   Ticket Tracker
Support
   Help/Documentation
   Community and Support Forums
   Links
   Administration Contact

This is just an example! Whether this should be a tree or a combination of top+left navbar is open, too.

Bye,
Waldemar

Mikael Jansson (mailing lists) wrote:
(sorry for this long e-mail, but I don't have the time to make it shorter)

Do we need a timeline/changelog of tasks and bugs? I like this very much because it is a good progress indicator. How could we do this with Bugzilla?

[snip Roadmap}

The point with roadmaps as I see it, is that milestones to which closed tickets are associated will be quickly filled up with green, making a real-time automatic status update. That information could also be dug up by looking in the Trac database; the general idea of using milestones however, helps a lot in making status Just Work(tm)

If you all think that tasks don't have to be tracked with a special tool and if you would beat me with a stick or feel uncomfortable with a switch to Trac then let's just fix Bugzilla and fully concentrate on the CMS issue.

Progress indicators should be in our project, and as stated -- it should be for the developers, not the other way around.

Tasks are for free with Trac. Could we get it up & running such that the switch would be smooth, developers (and users) would never again have to bother with manual status updates. Mind you, the milestones need not be linear, so having smaller milestones per team would be perfectly fine and as long as you'd have tickets assigned to them, progress would be made visible. This enables developers to do more work and less administration.

My point being: adding Trac to the project gives us slightly more work initially, but less work in the long run. I believe everything that shaves off runtime costs is worth pursuing, even though the initial cost might be high -- that's okay, because that time will be earned quickly as in effective developer time, and in a more active community.

Oh, another thing to add to the blog+tasks+wiki/cms+ticket centralization: screenshots (bug-nordic.org, haikuos tag on flickr.com, ...). Of course, screenshots, wikis and whatnot should be allowed on places other than haiku-os.org, but having one central place at which to find all information is certainly good for users & developers.

Imaginary haiku-os.org header nspired by the structure of djangoproject.com and similar:

[Haiku OS -------- | Status | Blog | Screenshots | Download | Issues]

Haiku OS: the mythical CMS
Status: akin to Trac's Roadmap feature
Issues: Trac (or Bugzilla, should we continue with that)

-- 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


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

Other related posts: