[development] Intelligent use of time (Re: Perm for setting RTBC

[Gerhard Killesreiter]

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

Augustin (Beginner) schrieb:
> On Tuesday 03 July 2007 01:29, Gerhard Killesreiter wrote:
>>> 1) won't fix 2 issues for 4.6
> 
> This actually illustrates my point. 
> Once an issue is in the RTBC queue, every other developper assumes it is your 
> responsibility to deal with.

Whose? Mine? I think it is everybody's responsibility to look at the
queue, regardless of the status.

> It took only 26 weeks to "won't fix" patches for a version that has not been 
> supported for I forgot how many months.

It didn't hurt anybody that the issues were sitting in the queue's last
page.
Also, it is possible that people use a queue that only lists the issues
for a particular version like:

http://drupal.org/project/issues?projects=3060&versions=97368

And again: Everybody could have closed them.

>>> and all of a sudden there are only 3 pages left...
> 
> For this particular queue, that's still 2.5 too many.
> http://drupal.org/project/issues?page=2&projects=3060&states=14

That is a matter of opinion. 3 pages doesn't sound all that much.

>>> The problem isn't so much that the core committers can't go through the
>>> many patches, the problem is that they are a bit shy to change status on
>>> stuff that doesn't belong there...
> 
> ?
> 
>> it takes simply time and _work_ to make it [the queue] shorter. 
> 
> Again, I thoroughly agree and that's precisely the point. 
> The aim was to unload the few people at the top that are the most overworked 
> of us all. 

Well, then help them and weed out the issues from the rtbc queue that
don't belong there.

> About 'time': not everybody is able (or willing) to spend the number of hours 
> that you spend on Drupal everyday.
> I am not. I can't. Sorry.

That's unfortunate.

> I was very active in the core issue queue for the D5 release. 
> But there are obvious systemic problems, and this (together with other 
> unrelated reasons) is why I decided to pass for the D6 cycle. 

So did I mostly, btw.

> Instead, I decided to use the little time I personally can devote to Drupal, 
> and concentrate on contrib modules, where my work can be more effective. 
> 
> It is regretable that the people who would have most benefited from using this 
> simple perm (the 5 core commiters), are also the ones who speak the most 
> strongly against it (2 of them, at least). 

For the purpose of the Drupal 6 release there are only 3 core
committers: Dries, Goba, and Steven.

> I am not one who usually say anything in "color of the bikeshed" threads. I 
> dislike empty meta-talk as much as many of you. 
> That's why tonight I started my contributions on this list with writting up a 
> stub for some docs that many have been speaking about (here and on IRC) 
> during the last day or two.
> Unfortunately, so far no one has made any attempt at improving my early draft.
> http://drupal.org/node/156119/revisions

24h notice isn't that much, give it some time.

> Anyway, since you seem unwilling to admit that there is a systemic problem, I 
> guess I'll carry on keeping out core, and stay in contrib instead. 

What I am thinking is that you are trying to fix a problem that is more
of the social kind with technical means. The social part seems to be
that Dries and others seem to be shy to mark an issue as "won't fix" if
they don't like the idea.

Fixing social issues with technical means never works.

> And precisely because, as you say, it takes "time" (a lot!) and "work" to deal 
> with the queue, I was eager to find solutions to make *better use* of 
> everyone's time. 

Yeah, but you also spent time doing so. :p

> You seem to favor brute force. I'd rather have a system that makes an 
> intelligent use of our time.

The system will also need to be written and this will take time too.

What I think would be a really nice improvement would be some way to
change the status of multiple issues in a queue...

E.g. a way to mark all issues older than 4 weeks "won't fix" if they
have the status "active (needs more info)".

> You may not remember, but I was the author of the 10 bi-monthly "Short issue 
> queue need care" dev-newsletter thing (precisely during the D5 release cycle, 
> during which I reviewed many patches). 

I do remember, that was very nice and I appreciated it a lot.

> The idea was a patch represents someone's time. I try to respect everyone's 
> time and not only my own. Those patches represent thousands of man-hours!! 

Yes, but only because somebody spends time on it, doesn't mean somebody
else has to spend also time on it too. A lot of patches are simply not
desirable for the general public (apart from technical shortcomings).

> 46 pages' worth of developers' time:
> http://drupal.org/project/issues?projects=3060&states=8,13,14,15
> I cry for the dozens of developers' wasted labor, when I see this list.

I don't. I think "These people have all had very interesting problems
that they managed to get solved and now they are even sharing there
code. Great!". The fact that the code might not go into Drupal doesn't
matter that much.

> I was trying to help the community focus on small parts of it, with the dream 
> that less developer-hours get wasted. 

Well, your newsletter did help me with Drupal 4.7.

> Your answer to this is: work more, spend more time. 
> And you basically say "shut up" to people who propose systemic changes so that 
> time is spent more wisely. 

Yes, but that's only because I am convinced that it won't lead anywhere.

Take as an example the "rtbc" queue. It was introduced when we felt the
patch queue that we use to have until then would get too long...

Now the "rtbc" queue gets too(?) long. I am sure the solution isn't to
have even more queues.

> To tell the truth, right before Dries replied in this thread, I had decided I 
> wanted to roll a patch fix the bug that Derek mentioned just earlier:
> http://drupal.org/node/121265
> But since you have decided not to use this feature, I guess I'll just shut up 
> for good, go back to core-lurkdom and keep to contrib-land.  

That's your choice.

Cheers,
	Gerhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGiVcYfg6TFvELooQRAnoMAJ9tygVpxQBIEB0BT2Y4a2My7yniMwCcC6Sm
5KsWxyp+1ujLc3qztxuJX6Q=
=DAS9
-----END PGP SIGNATURE-----