[csw-maintainers] Our core values: providing straightforward experience to the user

[Maciej (Matchek) Blizinski]

No dia 16 de Novembro de 2010 21:18, Philip Brown <phil at bolthole.com> escreveu:
> On 11/16/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>> No dia 16 de Novembro de 2010 17:00, Philip Brown <phil at bolthole.com>
>> escreveu:
>>
>> How does the release manager know what's the best for the user?  It's
>> not a rhetorical question.  I'm interested to know in the process.
>
> Maciej, we've been round this particular discussion at least 3 times
> before :-/ Previously, you have been asking with an eye to "well, tell
> me the process, and then we'll automate it".
> To which the reply has been, is, and always will be, "you cant
> automate EVERYTHING. Certainly, the things that can be, we should. But
> there are things that cannot be".
>
> If you are NOT asking in that "Give me machine readable procedure"
> context, but truly out of inquiry, then I will attempt to give you a
> good faith answer.
> (It's a pain in the butt. I WISH it could be more automated :) Your
> extra gar-checkpkg stuff has helped, which is nice)

Yes, this question it's not about automation.

> My registration script gives me a quick overview of what files are in
> the package, what dependancies it has, and what shared libs it uses.
> (maybe one or two other things i forget).
> For trivial packages, I usually just "wave them through".
>  **
> For new maintainers, I try to spend a bit more time digging.
> For new packages, I try to spend a bit more time digging.
> For packages that have changed (names, etc) I try to spend a bit more
> time digging.
> If I notice some odd pathnames, I query the maintainer.
> If I notice some odd/obsolete/non-optimal dependancies, I query the maintainer
> For packages that have not been updated in a very long time, I try to
> spend a bit more time digging.
>
> Some types of package I tend to wave through, UNLESS they have
> obnoxious names or other blatant oddities.
> eg: perl, ruby, and python packages.
> If someone wanted to actually spend TIME being a (perl/ruby/python)
> release manager, I would welcome the extra scrutiny. I myself am not
> qualified to deeply examine them, so I usually just pass them through,
> with the exception of the libpython, and "where do the scripts live"
> issues, which I attempt to keep consistent for the good of all.
>
> Some things that will be viewed as inconsistent:
> I have limited time. I'm not paid for this. So, sometimes, things get
> delayed, when I think, "this one should probably be looked at more,
> but I dont have time right now".
> And sometimes, I wave them through because they've waited long enough,
> and I just hope to look at them more 'next time around'.
> Or, "the maintainer has already done 10 of this type, I'm sure this
> one is the same"
>
> And sometimes, I was simply not aware of a problem the first time(or
> 2nd or 3rd) a package
> goes through. But after seeing similar issues with other packages, I
> will then hold up something to bug a maintainer, for an issue which
> they previously thought was okay.
> Sometimes, a particular thing does not seem like an issue to me at
> first. but then when I notice 3 or 4 packages going through the same
> way, my mind may notice something and say "Hey wait a minute!" and bug
> that maintainer.
> Nothing against that maintainer personally... its just at that point
> that my eyes happen to notice something in the file listings scrolling
> by, or whatever.

Thanks for the writeup, I've added a summary of that to our wiki:

http://wiki.opencsw.org/release-process

For the sake of next generations!  (Someone will see it and say "this
is wrong/bad/incomplete!" and improve it.)

>> I guess there's also the question of the reasons for rejecting a
>> package.  The release manager, despite having more power, can't reject
>> a package because, let's say, he doesn't like the maintainer.  There
>> has to be a valid reason.  I hope you agree.
>
> Of course.
>  I can say with all honesty that I have *never* rejected a package
> because I "dont like" someone.  Some people may claim that I have...
> but its important to note that they usually make this claim, instead
> of doing work to alter what I'm complaining about. If they had just
> done the work, they would have seen the package go through.
>
> Bad feeling may build up, when a maintainer goes through multiple
> times of rebuilding a package, but it's nothing about the maintainer
> personally. Its just that when I reach a problem, I say "fix this
> please", without looking further.
> Once they fix the problem, then I continue looking through it.
>
>
> What is unfortunate for positive feeling, is that I do usually look
> harder at a package that has had a problem already. NOT because I
> "dislike the maintainer", but because it is very often the case, that
> when a package has one problem, it usually has more. So when I hit a
> problem with a package, I do look even harder once I get a repackage
> of it.
> Not because I dislike the maintainer, but because I want our packages
> to be as clean for our users as possible. So where there are likely
> more problems, I look for more problems.
> I havent kept records, but it does seem like packages more often have
> 2+ problems, than just 1.
>
> and if you're wondering how I judge "problem", I go by our "core value":
> 'to provide a straightforward, easy-to-use experience for the user'
> The tricky bit is in balancing the needs from all of our different
> types of user: home, corporate, smallscale, and large scale. It
> requires a lot of human judgement. For which, I use my 7 years
> experience as a release manager, and 20 years experience as a
> sysadmin.

I think your contributions to the project in terms of examining
packages and discovering issues, are really valuable.  I admire your
patience and insight.

However, the 20 years experience argument leaves me unimpressed.  I've
seen people with 15 or 20 years experience, who, when asked to write a
shell script, write something that doesn't work, and asked about the
big-O notation of the complexity of the script, can't work out the
answer.

At the same time, the 20-years experience people are those who learned
to put up with crap around them, and would rather continue to do that,
instead of introducing change.  It's the fresh people who notice crap
and have the energy to improve.  So, if you want to reason from
experience, it works against you as well, experience makes you also
ill-equipped for making decisions.

What I asked in the original question, was _how_ do you know what's
best for the user.  You've described the fact gathering part (package
examination).  I'm interested in the process that happens afterwards.
I guess have some sort of a mental model of the OpenCSW-related part
of the world.  Then you have our core principle of providing
straightforward experience to our users, and you somehow match the
two.  I'm interested in what does the model consist of, and what the
evaluation process looks like.  You need to operate using incomplete
and imperfect information, so you need to use heuristics, or skip
evaluating some parts of the model.  I'm interested in what does this
model comprise of, and what does the process of evaluation look like.

-- 
Maciej

95e7d4ae28961661d8b34c6399e4b6c4