[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Maintainer Responsibilities

On Thu, Jun 4, 2009 at 11:37 AM, Ralf Corsepius <rc040203 freenet de> wrote:
> David Tardon wrote:
>> Let me try another analogy: How do you handle health problems?
>> You'll visit your doctor. You'll expect him to identify the problem and
>> to take appropriate steps to solve your issue--that may well be just him
>> sending you to a specialist.  Would you expect your doctor to serve as a
>> proxy between you and the specialist? Or even substitute you for
>> checkup? I wouldn't.

That, in fact...is...exactly how it works.

There's too much knowledge.  A general-specialized entity has to
forward clients to a super-specialized entity for super-specialized
service.  You can't expect one entity (when the entity = human) to be
able to do everything.

Don't use that analogy.  It doesn't help.

In my opinion, you're all missing the big picture.  And in my
audacity, let me suggest it.

1.  End-users should be able to seek out support when they need it.
You all agree.
2.  End-users should be expected to go to upstream with their issues.
You are split.
3.  Maintainers should be expected to go to upstream with end-user's
issues.  You are split.

Support != upstream.  It's a symptom of the fact that the open source
community is where people who create goods often don't do top-down
support of those goods to end-users, the final recipient.

Here's the problem:  You all agree that end-users should seek out
support.  The reason why "they should go to upstream" is split isn't
because Seeking Support = Bad.  Seeking Support = Good.  You're split
because Having Outsiders Navigate Two/Three Layers of Community
Indirection = Bad.

In terms of navigating the community, open-source is as bad as any
bureaucracy.  It says "Let me forward you to X", when getting to X is
appropriately daunting, and by the time you do you don't even know
what to tell X.  It's not "who should do it", it's "what do these
users have to go through?"

That's your problem, so rephrasing it in terms of "who should have to
do the upstream contact?" is not the problem.  That's delegating
everything to one entity.  End-users, package maintainers, upstream.
One has the user experience.  One delivers the user experience.  One
creates the user experience.

Sadly, 2 and 3 aren't the same person.  There must be a system that
can allow 1 and 3 to talk directly, easily, without worrying about any
adverse factors that 2 might have stuck into the works.  (It does no
good for end-users to work with upstream on packages that upstream
doesn't even understand).  Until someone is a genius enough to come up
with these ideas, you're always going to have problems.

So for the here and now:

1.  Assume the average end-user will be of no help -- he should be
expected to seek support, but he cannot be expected to navigate the
open source community.  A few will, but to be super-effective the
barrier to entry must be drastically lowered.

2.  Maintainers must realize that de facto -- even though it isn't
ideal -- they'll have to take on some burden of upstream contact.  And
accept it.  (While being a little grumpy.  That's probably okay.)

3.  You need an easier way for users to file for issues.  All
necessary metadata information gathering (versions, kernel, package
names) should be automatic.  The system should be smart enough to do
that.  (It seems like Fedora is getting there with its new reporting
tools and on-demand debug utility.)  Let the end-user do the only
thing he can:  describe what went wrong in plain english in a
text-box, and then don't burden him with anything else.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]