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

[Augustin (Beginner)]

I'll try to keep this short :)


On Tuesday 03 July 2007 03:50, Gerhard Killesreiter wrote:
> > 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.

I wrote: people *assume' it is your (you 5) responsibility. The assumption is 
Green == commiters' job. People are eager for a commit. Once someone gives 
them a green light, they are mostly waiting for what you will say, hoping for 
a commit that only you 5 (depending on the branch) can do, so the assumption 
is not totally erroneous. 



> And again: Everybody could have closed them.

The two outdated 4.6 issues, yes.
But behind most of the other green patches, there is someone hoping for an 
illusive commit. 


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

Either they are going to get committed, or they are not. 
If they are not, the earlier coders know this, the better: they'll stop 
earlier wasting their time on that particular issue.
If they are, why not commit them straight away, as they are being set RTBC 
while the patch still applies.

Constantly re-rolling patches also takes time. 

That was the point of what I proposed. Dries complains it takes a lot of his 
time to review RTBC patches. I say: let's have fewer of those, and have them 
better reviewed, having culled the unwanted patches much earlier in the 
process. This way fewer make it to the top, and the commiters have fewer to 
review themeselves and can commit them as they are set RTBC. 
This leads to shorter queues, less needs to constantly re-roll patches, less 
frustration, less time elapsed between drafting the first patch to the 
commit, etc. 


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

For Drupal, maybe. But there are other Drupal developers.

It is less unfortunate for the people and causes I spend my time helping 
instead.
It is a question of personal priority. 
But I do try and like contributing to Drupal at least to some extent. 

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

Yes, I knew. 


> > draft. http://drupal.org/node/156119/revisions
>
> 24h notice isn't that much, give it some time.

Yes, you are right. It was silly of me to whine about my half page, while 
others have wasted time on dozens of page of now useless documentation :-/ 
I offer my apologies.

I was only thinking to promote this page while the topic was hot.

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

If this is true, it is a grave mistake by Dries, and that is causing much 
frustration. The earlier he does shouts "won't fix", the less time people 
would waste time on patches that have no chance. 
That's all I am talking about. Conserving time since everybody seem to feel 
they don't have enough of it.


> Fixing social issues with technical means never works.

That's a very interesting idea, and I'll think more about it after signing 
off.
But my proposal has a strong social aspect that you obviously missed. 
The technical aspect was simple and easily implemented: use one more perm.
The social aspect would have been like saying: please us your worth, prove 
your reviewing skills, show you understand Drupal's architectural philosophy 
and coding standards, etc, to earn the right to set issues RTBC.

This system works very well already for the documentation: anybody can add 
book pages, but only after having contributed enough does one get more rights 
to become a documentation team member (I don't know the precise name of the 
role you use at d.o. that gives more relevant permissions). 

It is the same here: add one more level of peer review - which is definitely a 
social issue - just like the documentation team is having. 

So I claim that my proposal was mostly one of social engineering to solve a 
social issue (with the help of an existing technical tool that is already 
being used widely throughout d.o.: roles and perms). 

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

The hope is to be able to save more time in the long run. 
I usually never intervene in meta-talk threads. Tonight is the exception: I 
was hoping something positive would come out of it.
I guess I was mistaken. 

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

Adding one permission? Adding one page of documentation? 
What is that compared to the potential social benefits?
I already offered to work on the bug.


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

Yes. Like me, you'd spend some time doing something in the hope of saving 
plenty of it later down the road. 


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

Thanks :)


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

That's what I mean: if they are not desirable, we *ought to* find a way to let 
the coders know about it very early in the process, before they waste their 
time and get frustrated because they don't get the commit they seek.


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

Well, to me it matters that people are wasting time. It's less energy that 
could have been spent on doing something which would have given concrete 
*results* (better Drupal).

If a developper I barely know is wasting her time, it also means to me that 
I'll get a lesser quality Drupal than I could have gotten. 


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

Ok. I don't mind that much about my own little idea. It's just a shame not to 
use it. 
I am hoping that Dries (and you) would listen to other people who have very 
good ideas of their own, and heed their advice.

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

I was not offering a new queue. Just use a permission that is already coded. 

> That's your choice.

yes :)

thank you,

Augustin.


-- 
http://www.wechange.org/
Because we and the world need to change.
 
http://www.reuniting.info/
Intimate Relationships, peace and harmony in the couple.