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

Waldemar Kornewald <wkornew@xxxxxxx>:
>
> 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
> 
To me, it sounds like "Support" and "Ticket Tracker" belong to the same 
area. Blog should maybe be emphasized a bit more.

Also, I strongly dislike overlapping information, say "Help/
Documentation" vs "Community and Support Forums", or "Documentation" in 
Development vs "Help/Documentation" in support.

I think less is more. Start with the absolute minimal areas and 
continue from there, instead of doing too much and ending up using only 
half of it, making ourselves confused on the way ("Where was the build 
customization doc again? Support -> Help, or was it Development -> 
Documentation?")

Things like that.

-- Mikael

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


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