[Tracker-discuss] Feature/Change request handling procedure

[Stefan Seefeld]

Martin v. Löwis wrote:
> Stefan Seefeld schrieb:
>> * What time scale should we expect this whole migration to take to
>>   move forward ? Would it make sense to set up a time frame to not
>>   let this drag on for too long ?
> 
> I think so. Some people (GvR in particular) have been asking why
> this isn't completed, yet.
> 
> It would be good if it completed this year.

I agree that would be good, and I think it is possible, at least
technically.

>> * I have made various fine-grained change proposals on the meta
>>   tracker. Would it be more efficient I made an overall proposal
>>   that allows to think in terms of the 'big picture', instead of
>>   piece meal changes ?
> 
> I think people won't respond at all to tracker schema changes,
> no matter how much feedback you request. Instead, they want to
> see the complete solution, life.
> 
>> * What exactly do we need in order to consider a change to be
>>   approved ?
> 
> The tracker team can do whatever they want, IMO. The infrastructure
> committee should back them up and support them as long as we had a
> chance to comment.

OK, fair enough. So, let me present a little hand-drawn schema I'm aiming
for, with some comments. The goal is to allow users to report bugs with
as much detail as possible, without getting into their way. All properties
are typed (i.e. use links to predefined entities), instead of simple strings,
to avoid typos and make querying easier.

Roundup's permission handling, together with auditors, should help us
keeping the workflow / bug lifetime streamlined, i.e. make it obvious to
everybody what the potential state transitions are.


Schema
------

bug = (title,
       messages,
       files,
       type,
       components,
       platforms,
       version,
       severity,
       dependencies,
       status,
       resolution,
       superseder)

pep = (title, messages, files, ...)

milestone = (name, messages, eta, bugs, peps)


Comments:

* type is an enum helping to classify the bug. For example:
  (crash, compile error, resource usage, security, rendering, behavior, rfe)

* components expresses what parts are affected

* platforms expresses what platforms are affected

* version is an enum to express the python version (or branch) the problem
  occured in.

* severity is an enum allowing users to express the impact the bug has on them,
  such as: (critical, major, normal, minor)

* dependencies: a list of bugs that need to be fixed before this can be fixed.

* status: one of (new, open, closed)

* resolution, set when status is set to closed: one of (fixed, invalid, duplicate)

* superseder: a follow-up bug, if resolution is set to duplicate.

* milestone is an issue type useful for release management. With it it is
  possible to query for bugs / peps to be closed for a given point (release / time)

* pep is a placeholder for PEPs, just to illustrate that this tracker can grow. :-)


Access
------

Users submit bugs, setting title, and optionally components, platforms, version,
and severity.

Developers set assignee, status, resolution, dependencies, and superseder.

Conversion
----------

Conversion from sf.net should map 'category' to 'components',
and 'group' to 'version'.



If there are no objections, I'm going to start to implement it.

Comments ?
		Stefan

-- 

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