Respulsiveness [was: Re: Call for a meeting (IRC/Hangout)]

[Xen]

Hi Satyajit, thank you for your discussion.

Quoting Satyajit Sahoo <satyajit.happy at gmail.com>:

>>
>> All that user wants is for the gift to be accepted. But you usually
>> turn down such gifts very rapidly. You quickly say why it's a bad
>> idea. I think I can find numerous examples if I dig in the lists.
>> Charlie Moss, would perhaps of course be just one example, If I may be
>> so bold to include him here, seeing as that he has already left.
>
>
> So, basically what you are trying to say is, when someone tries to
> contribute, we should accept his contribution, to encourage him, right?
> You're right, but you are a bit biased. You don't see from the viewpoint of
> the project.

That may be as it may (not seeing it from the viewpoint of the  
project) but I'm not really defending either side's view. I'm trying  
to make you see that your own attitudes and actions do not help your  
own project.

>
> What if someone comes and says, I don't like GNOME Shell, use GNOME Classic
> by default in Ubuntu GNOME?

People usually don't come in with such blunt statements.

>
> Well, he is right at his position, and he sees GNOME Shell as a bad thing,
> and wants to improve Ubuntu GNOME by getting rid of the bad thing.

Perhaps if He had very good reasons, his task may not be to make you  
make another choice, but perhaps merely to make you see something you  
didn't see before.

People who come in with ideas don't expect them to be followed up  
instantly. What they are hoping for, I guess, in my case, is something  
much more modest, but at the same time more inspiring. They hope that  
a certain complaint or vision is getting heard. That is really the  
only thing that matters.

Because once other people (the ones involved with the project) see a  
certain perspective that is offered to them, it really doesn't involve  
much more pushing or pressing.

You can't get people to do anything they are not enthusiast about  
anyway. That works on both sides. So when you present the idea or the  
trouble or the issue, you only want it to be understood.

Once it is understood, or once someome's views are seen for what they  
really are, there is no longer any real disagreement. Usually what  
happens is this:

1. I have some good idea!
2. Your idea sucks.
3. But really, just look at it this way.
4. No, sorry, It Can't Be Done.

((- I have often offered alternate views on a variety of sites and  
mailing lists about a variety of products. My views were often  
ridiculed just because they were different or new or not-seen-before.  
If you can only stop ridiculing or short-cutting or short-stopping  
new, ill-understood views, you would gain a whole lot, actually the  
entire world. -)).


> What do we do in this case? Agree with him because his motives were good,
> and he wanted to contribute? Of course we cannot do that. If disagreeing
> with him drives him away, what could we do to stop that? We cannot agree
> with him just for the sake of keeping him, right? If his views don't align
> with Ubuntu GNOME's, we cannot do much to keep him.

It is not about disagreeing, but the way it is being done.

Usually it is not about the what, but about the how.

If you can make the user feel (the person) that his views have been  
appreciated and understood and listened to, that user doesn't want  
anything else.

If you give him/her the feeling that he was wrong to offer the  
suggestion in the first place, then he will not return (eventually).


> You are pretty much saying "accept things as they are, work with it,
>> do not try to go against it, and you may get somewhere". But that's
>> the sort of thing you say to a new employee that you really want to
>> exploit. That's the sort of thing a crime boss might say to a new guy,
>> or some employer might say to an employee or newcomer he/she wants to
>> work to the max and ensure .....
>
>
> Seriously?

Yes, seriously. Because a person doesn't need someone else's approval  
to just get somewhere. A person does not need someone's "allowance" to  
be able to be successful. Sometimes success or opportunity is seen as  
a gift. But it's not, you create it yourself. We have all been led to  
believe that we must bow our heads to become something. This is  
typically what was being expressed here.

"That is not how you contribute to open source, start small, build up  
trust and respect and then you can move onto the bigger ideas!"

No, that doesn't work. That is a very dysfunctional way of doing  
things, and very very ineffective. It almost feels like some attempt  
at hostile take-over. You integrate and infiltrate with the project  
until finally you can take over its course.

The best way, in my opinion, to contribute to open source, if you will  
have that, is to simply take the product, see what you can change  
about it on your own accord, and start supplying patches. You must  
follow your own directive and do it for your own reasons. But that  
only works if you are a developer. And in the position to develop, and  
in the position to change the product.

You can hardly change the product called Ubuntu Gnome.

Ubuntu Gnome is more of an idea than a single product. It is more of a  
community, or a thought. So to change or contribute to Ubuntu Gnome is  
not to ask "please, what can I do?" but to simply start describing  
what could be better or different, or what is not currently working.

The product is too volatile, to ever-changing, to much up to dispute,  
not solid enough... to really start contributing from the get go by  
doing stuff for it.

Sure you can make themes, or backgrounds, you can work out new schemes  
(perhaps software setups) and develop that and propose that. But apart  
from that: it is a distribution. It is a tightly organized thing,  
effectuated by a team. Since the team controls it, if you want to have  
any say (or sway) the only thing you can do is talk to the team. Minor  
things can be done, but anything bigger you need the cooperation.

For something like Ubuntu Gnome (or Kubuntu) the sort of thing you  
might start doing on your own is: to write documentation (wiki), or to  
make videos, but if everything is so tightly organized and packaged,  
then you need to get involved with the team or teams or community for  
that also.

And that is troublesome. The product is very much a marketing effort.  
You said (below) that Ubuntu Gnome is a very large project, but I  
don't think it is.

Even Kubuntu (r.i.p?) is not a large project. It relies on a very  
small number of people. That work very very hard. It is difficult  
work, package integration and merging and all that. There is also not  
a lot of point to writing Kubuntu specific documentation, for  
starters. Kubuntu (if we were to speak of that again) doesn't add that  
much to KDE. So you can hardly redo the KDE documentation. Most of  
what users need to do comes from other projects. KDE and all of the  
components of a Linux system. Kubuntu has a wiki but I was never  
enthralled by it.

If you seriously wanted to, you could create a single, well-structured  
Ubuntu-wide documentation system with 'branches' for each of the  
deriviates, so you don't do the same work twice. But I don't see that  
happening really. Ubuntu documentation itself is "not of stellar  
quality" as someone once wrote.

I have never read with any sense of joy the documentation of Ubuntu. I  
have, however, if I was allowed to mention such, had some joy reading  
documentation of other Linux distributions. It all depends on the  
scope and how many people really feel at home with the system, and are  
willing (and able) to spend time on making it better. It is nearly  
impossible to join the Ubuntu Gnome or Kubuntu teams.

The wiki(s) is badly organized. There are / is distrubtions that have  
excellent (DocBook) material, a real user's guide. A site that is  
well-made.

By contrast, and you have to see this for what it is if you want to  
understand your difficulty in getting somewhere...

Kubuntu and Ubuntu Gnome are *ALWAYS* short of people to help them.  
There is always this sense of urgency. There are ideas, but there is  
no solidity. There is mention of having a better website, but...

That should really be a given and not so much up for debate. It feels  
like you are always short on energy, short on manpower, short on  
everything.

How can that be????.


>> People want to first get their idea accepted. Then they want to work
>> on getting it realised to some extent. Then as the process goes they
>> want to become a part of the community they are entering. Then they
>> will seek to expand that community or enterprise, or expand their own
>> involvement, ideas, etc. Then they will want to learn about the bigger
>> ecosystem. It goes in stages.
>
>
> Yes, people do want that. But you are forgetting that, we're a large
> project, with many members. There will be conflicting ideas. There will be
> ideas which won't fit with the project's goals. We cannot accept every
> idea, just to expand our team. What we want in the end, is a good product,
> to make Ubuntu GNOME better. We've to make choices to be able to do that,
> and yes, those choices will conflict with some people's views. There is
> nothing anyone can do anything about that.

Then talk about your ideas. Discuss them. I'm not sure if you (people)  
are very clear on (your own) ideas either. I feel there is not any  
debate on this list, and attempts at debating something are quickly  
turned sour. They are not welcomed. They cost time, and you feel like  
you don't have any.

The best location, by the way, to discuss the product itself is not a  
mailing list but a real newsgroup. In any case something that could  
happen on Google Groups.

I have often been told that "these are SUPPORT forums" (in other  
words, not meant for discussion or debate). But discussion is important.


>> But what you are now wishing for, expecting, hoping or demanding that
>> users do, is to reverse that process. You want them to first accept
>> like Ubuntu Gnome as their group. You want them to recognise the
>> community and what they've done and what they're doing. Then once they
>> are "in the group" you want them to perform duties for the group. Then
>> finally you want them to have ideas.
>
>
> Yes, I think that's logical. Acceptance should be from both sides. We've to
> accept the users, and users have to accept us. It doesn't work one way. We
> cannot just accept someone if he doesn't accept our views.

It's like you're trying to argue with your users whether they should  
qualify as contributors or not. You're putting up barriers. Don't you  
see you're not arguing with me, but with yourself???.

Do you really WANT new  
developers/helpers/thinkers/doers/creators/artists, or not?

I think you haven't really answered that question yet.

If the answer is univocally yes, you will start to change your attitude.



> And the authoritative nature of some of the groups here (I have only
>> witnessed the design team) doesn't help either.
>
>
> You don't tell a coder how to code. That's why he is a coder, and not you,
> because he can code better than you, unless you're a coder. Why shouldn't
> it be the same for designers?

You're really talking to the wrong person, because I've been coding  
since I was the age of 8 or 9, and I'm 34 now.

> Ever try telling a coder how to code, and I promise, you won't get a nice
> response. I'm just stating the reality.

Only if the coder is a stuck-up prick that thinks he knows everything  
and can learn nothing. Just stating the reality of many coders around  
open source.

I see a LOT of bad software okay?

Myself, I can't brag about much, but I've at least programmed in MSX  
Basic, GW Basic, QBasic, Turbo Pascal, Borland Pascal, Turbo  
Assembler, Borland Delphi, Java, and later PHP. I went to university  
where I learned almost nothing, although the courses on Data  
Structures (in Java) were nice. I learned nothing programming wise  
because most things I had already done. But I was introduced to formal  
OO concepts, some algorithms, interface/implementation abstraction, I  
done a bit of C, C++, Matlab, Prolog, CaML, of course SQL, UML, and  
some organisational modelling (DEMO, it was called) and I believe our  
University was high on that area, modelling data systems and doing  
architectural design.

In any case I must have spent I guess about I don't know, 4x20x365 =  
some 30.000 hours programming to date? Or at least time spent  
concerning computers and everything that involves it.

So I can't brag about much, but I recognise good and bad software when  
I see it. I also recognise good and bad architecture when I see it. I  
was never of the quick 'n dirty type.

>
> Why should anyone do work they don't want to do? Just so that YOU will
>> finally accept them? As part of the whole, the borg, the group?
>> Assimilated.
>
>
> Because he finds our project interesting, because he wants to contribute to
> something he loves. And how can he love our project if he disagrees with
> whatever we say?

It's not that he disagrees whatever you say, it's more like you  
disagree with whatever "he" says.

You are the ones who have a position to defend.

You are the ones who are impervious to new ideas.

Love goes a lot deeper than just being in agreement.

> I'm all happy when someone new wants to contribute to the project. If he
> has new, interesting ideas, which improve the project, I'm all for it. But
> if his ideas conflict with the existing ideas, unless it's a better one, we
> cannot just sacrifice the existing ideas.

That's when you get debate or discussion, or at least exploration and  
evaluation, but I see these things are rarely done in this list at  
least. You feel threatened, apparently, by new or deviating thought.

For example, you sometimes speak of a target audience. What is the  
target audience of Ubuntu Gnome?

 From what I SEE happening, it is:

- novice users who don't demand much of their computer
- site kiosk computers.

But I don't see much public debate. And it is hard to voice anything.

> Again, try being in our position once and have a good look at it. Say you
> had a project. There were some people who were actively involved and you
> all had a view of your project's direction. The next day someone new comes
> in. You're happy to see him, but he wants to change things, which conflict
> with your views. What would you do?

It depends. If that person is only coming in to suggest that you may  
be on the wrong track considering where you want to go, perhaps it  
would be time to listen to him/her.

Perhaps that person wants to help you to become clear on where you want to go.

Perhaps that person wants to talk about goals rather than introducing  
new ones.

Perhaps not everyone coming up with an idea is adamant on it being  
followed to the letter.