[Tracker-discuss] schema ideas

[Stefan Seefeld]

Paul Dubois wrote:
> a. I do not favor a 'severity'. Without some big long discussion, let me
> lose all the nuance and summarize it as 'useful for user indicating how
> mad they are, and letting off steam, but not useful to us' and
> 'experience with sf tracker'.

OK, so do you agree that the priority attribute is removed, or at least,
made unavailable to users ?

> b. The suggestion that we call issue bug doesn't make sense to me very
> much. We have by default issues that can be categorized as bugs,
> features, wishes, etc. In my tracker we have an FAQ priority as well.
> Probably the confusion is with the word priority more than the word
> issue. I realize you could have an entirely new class with its own
> handlers, but we can fight that war when it breaks out.

I was specifically thinking of things such as PEPs that we may add support
for later on. All this falls into the broad category of 'issues', and so
I'd just point out that right now we are discussing bug tracking only.

> c. The best way to screw up an operation, as the Japanese found out at
> Midway, is to make it too complicated with too many pieces. We don't
> really need a comment period, for example: we have already been selected
> by such a process, and we all know it is a good product, and we all know
> we can adapt it over time if we need to. Let's just run it out there,
> without any new pieces that can break. If the standard help is not
> enough to suit you, you can had some 'what does this mean' little links
> next to words like priority and have it go to a text page that explains
> them all.  I'm for stopping SF on a date certain, importing, checking it
> out ourselves, and then turning the public loose on it. I've actually
> never seen anybody need any instructions to use Roundup.

Yes we have been selected, based on roundup's capabilities. I'm not sure
whether that actually implies that the schema used for the prototype is
already optimal. I for one don't like the schema used at sf.net at all,
and so I'd break more radically from it during the transition, since
now we can.

> d. It is not a good habit of mind to try to make it 'like sourceforge'. 
> The problem with involving pythondev too much is that those who know no
> other way may overlook the ways in which 'native Roundup' might be
> better. I remember a fellow in my office who refused to have a glass
> terminal and who had elaborate explanations of why -- until about 2 days
> after he'd had a glass terminal instead of a paper one. Committees make
> damn poor achitects. I'm not saying don't ask customers what they want,
> but I am saying we have to lead.

We are in violent agreement. I have configured many roundup trackers in
the past, and always was pleased with the results. I'm certainly not
trying to make things complex. Quite the contrary. I'm trying to
find the ideal vocabulary that fits into the actual development process.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...