Vision for Kubuntu

[Óscar Fuentes]

Xen <list at xenhideout.nl> writes:

[snip]

> On those public venues, which are supposed -- at least that's what you
> would think -- to be places where people can freely talk, free talk is
> actually not allowed and all messages are continually monitored to
> comply with the mission.

This is expected and reasonable. It is what I see on most, if not all,
projects that I follow, unless the admins are asleep at the wheel (or
simply too busy to do their duty.)

[snip]

> It is virtually impossible for Kubuntu to become involved as e.g. a
> documentator, because there are no freely available places where you
> can document. Free spots for "little work" are not available, and
> hence only "bigger positions" are up for offer, that require real
> commitment and big tasks to perform, effectively.

Do you mean that if you submit a patch adding a small piece of
documentation or simply correcting some typos, it will be
rejected/ignored?

[snip]

> So they must indeed, completely, create their own project and create
> their own space in which to do these things. But this is hardly
> possible if you cannot talk to anyone *also* using the systems that
> you yourself use. How do you get in touch with e.g. other Kubuntu
> users if the Kubuntu channels themselves are not allowed for doing
> that?

What people do is to post *at* *most* one message on the mailing list
saying "I'm starting a new project blah blah blah, follow-ups to X". But
it is unacceptable to use the original project's communication channels
for promoting your own project or to use them as if they were your own.

[snip]

> And simply put: communication precedes activity.
>
> Talk precedes doing.
>
> Design precedes implementation. So by blocking that first step, the
> 2nd step also never arises and you are left without recourse, or, as
> is said in Spanish "sin remedio".

I know that, in theory, it should be that way, but that's not my
experience about how things work. Every now and then someone appears
with a significant contribution and *then* it is discussed. Sometimes it
is rejected outright, sometimes changes are required but those are never
implemented and the work is lost... Project maintainers are not prone to
enter on lengthy discussions because they know that most of the time it
is a waste of time. They very much prefer facts instead of words.
Moreover, while refusing to enter on a philosophical discussion says
nothing wrong about the maintainer (although the would-be interlocutor
may think otherwise) ignoring a patch without proper review will
seriously damage her image on the community.

[snip]

> And so of course it is correct that a project management is allowed to
> do these things. But that is *not* an open source community. The whole
> idea of open source is that you *are* allowed to do with it what you
> want, and this *actively fights that*.

The communication channels are not different from other project
resources (web hosting, version control systems, bug tracking, etc.)
Taking measures for ensuring that those resources are being used
according to the project's goals is reasonable. If they think that an
user is either mounting a revolt, recruiting people for a competing
project or simply creating noise, it is their duty to stop that user's
activity.

I'm afraid that you have the wrong idea about what an Open Source
project is. Catch phrases like "everybody is welcomed", "we are a
community", etc. have not the broad meaning that you seem to attach to
them.

[snip]