[Tracker-discuss] schema ideas

[Erik Forsberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. Löwis" <martin at v.loewis.de> writes:

> Erik Forsberg schrieb:
>> Before we do this, perhaps we should establish some procedure to
>> handle all suggestions, to make sure we don't miss anything, and also
>> to make sure the suggestions favoured by most people get implemented.
>> 
>> I have a feeling that the python-dev people already have a procedure
>> for this? Our meta tracker should of course be part of it some way. 
>
> Not sure what "this" is, but the answer is likely "no". If "this"
> is "changes to the tracker", then no: there was zero chance that
> SF would ever listen to our requests, so nobody bothered with making
> any suggestions.
>
> If "this" is "changes to the infrastructure", the people request
> them by posting to python-dev. Either somebody responds, or they
> either forget/give-up, or ask again after some time.
>
> So letting them post to tracker-discuss would be a reasonable procedure;
> OTOH, if they are told to put it into roundup, they also will.

Sorry for being unclear, I'll try to rephrase.

What I meant was that perhaps "we" (as in, "the people actually
implementing the new tracker") need a way to organize the suggestions
on features/changes to the tracker that people from python-dev suggest. 

I agree with Paul - it's important not to make things too complicated,
and I fear that we might get into a situation where we discuss pros
and cons of lots of suggestions never getting to the point where we
feel that we can go live with the new tracker.

How do we find out which features/changes are so important that we
_must_ implement them before going live, and what features/changes can
wait until later? Let's not forget that the tracker is not finalized
once it goes live - it can be improved later, and now when we have a
tracker software that is open source, requests for new features can
even be answered with the infamous "Patch welcome!" :-)

Perhaps I'm just an old lady with blue hair worrying too much? :-)

http://www.python.org/dev/process/ tells me that there is an "informal
voting process" that is sometimes followed on python-dev. Perhaps we
could use some variant on this. Here's a proposed way to handle
feature/change requests:

1) Feature/change requests must be added to the meta tracker. The
   priority should be set to 'wish'.

   (We might want to setup a detector that sends this list a mail
   whenever there's a new issue, and when there's a comment added)

2) Once it's in the meta tracker, let's discuss it, by making comments
   in the tracker. If someone has really good arguments on why a
   specific issue should be implemented before going live, here's the
   chance to publish them in a structured manner.

3) After a short period of discussion, let members of python-dev vote
   using the protocol outlined in
   http://www.python.org/dev/process/. This can also be done by adding
   comments to the tracker.

4) Issues that get many +1 and few -1 can be moved up to priority
   "bug", which means "must be implemented before christmas, ehm.. I
   mean before going live"

   Issues that get a few +1, few -1 and mostly +/-0 can be moved up to
   priority "feature" which means "good idea, but let's wait and do it
   later".

Does this sound like a good or bad idea? Other ideas on how to handle
this problem? Is it a problem at all, or should I just cut that blue
hair? :)

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFWW1NrJurFAusidkRAmW0AKCZTKLiHNjGufmVKfaKhKb2IBky2ACgl8vW
sIERFig1JJE5h09s2NOHXV4=
=hMVq
-----END PGP SIGNATURE-----