About better communication in the community

Hi Stef,

2016-08-25 3:48 GMT-03:00 stepharo <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;stepharo@free.fr&#39;);" target="_blank">stepharo@...>:

Hi hernan

Could you reply to my mail? Because what is important is how we can make progres.

Ok, here it is :)

 

About GT I have some concerns too now I see also a lot of improvements. I love GTInspector and we should remove EyeInspector.

I want to have once brick is out another minimal environment not based on anything so that we can have a back-door to debug when the other tools have a problems.

Cool you are considering this situation.

 

Now some answers:

Then it makes no sense raise any form of criticism, or the board, if by definition lobby groups silence any possible mistake.

No this is wrong. You can criticize as I criticize but you should give clear actionable points.
Else this is Oh XX is bad.
Tell us how we can address your problems and we will try.
Without clear feedback we cannot act.

I'm afraid my english is good enough to provide clear feedback. I try to do my best without offending anyone (see below)

 

2. Features that goes inside Pharo are not decided by vote. They have to add value and share the Pharo vision (pointed in the vision document who is not slightly updated but still guides our steps). We try to reach consensus and if it is not possible, then we decide. Yes, is like that… I’m sorry for not being perfect democratic but this was never the idea of Pharo (it *has* a benevolent dictator… who by the way is not me but a group, the board). 

Ok, now people can see one reason why Pharo is light years from the popularity of other OSS. I don't get how do you expect success with Pharo if you never change your mindset... I read a lot of papers and see KDE, gcc, Linux, NetBeans, Python, Mozilla, Apache collaboration models... never *ever* read something like that, specially now where OSS literature is considering distributed democracy.

Sorry but
    - you would be surprised by how many people would vote to get GT tools inside Pharo :)

In my opinion is because it is biased by the same people who is behind, or invested time testing/fixing it, and we are few to have a valuable N. This will never be fair, newbies will ignore the old inspector/explorer (yes, the old one from Squeak) was just fine and was easily understandable and extensible just adding a few methods. And, I repeat in my opinion, a new inspector isn't really a high priority for our world problems (big data is, for example), much less a framework.... So that's my view on it.

But that's all, decision was taken. Now we have to move on.

 

    - then I do not know what to tell you because I'm quite sure that Apache or Mozilla are not managed by vote of people.

Just a few references you, or the board, may consider for the future :

Python: https://www.python.org/psf/membership/#who-is-allowed-to-vote
KDE : " A "KDE Core Team" uses a democratic voting procedure to resolve important issues "
Apache HTTPD : " Proposed changes are voted upon via mailing list; 3 yes votes with no vetos are required to commit a change "
Mozilla : "A review and super-review process is required for most code changes."

http://flosshub.org/sites/flosshub.org/files/HalloranScherlis.pdf

"It is important to keep users involved in the process and not treat them as second-class citizens."
Richard P. Gabriel
http://www.dreamsongs.com/IHE/IHE-52.html

In the end, time will tell, but can you cite another successful open source project with such "model"?

Sorry I do not have the time to know.
We want an doit model: doing in things should be more important than suh having needs (even if clients and users are important)

4. You have a very negative opinion about our design choices. That’s ok, but we are not going to remove GT just because you dislike it.

It's not because of just my dislike. It's because it was never proposed for inclusion (it was just decided), it is because you make it almost impossible to uninstall it, and because it was integrated very early like an enhacement/future/vision set of tools without any votes, or high-resistance policy like many Open-Source projects, and judging by the volume of mails it required a lot of of time of beta-testing by many users.

You mean beside me someone was not really happy?
Seriously?
Now you can not use Spotter so I do not see the problem.
The Debugger is working well.
Playground looks like a default workspace.
Then GTInspector works perfectly for me.

To be clear, it's not against GT specifically (I don't like it, too slow, takes too much space, etc) but the integration process behind, where the board delivered it and seemed to said f**ck you this must be loved, deal with it if don't. But then we don't have an easy way too uninstall it, I have to spend days investigating how to remove it disabling settings in specific order, and without leaving obsolete instances all around. So what's my proposal for a next release?

Respect the freedom of choice for people which is not obligated to love all your tools, by providing an uninstall option (if the tool is not really essential)

 

I would love to have the time to invite you, or any GT developer, to work with me just one week with real DNA data, and see how well GT goes...

Please do a skype sharing session with Andrei and Doru. I'm sure that they will love to do it.
So I take your words and urge you do it.
It will help you to get out your frsutration and I'm sure that GT will improve.
So a clear win/win situation.

This is hard for me because I'm sure at this point Andrei and Doru should be angry with me for ciriticizing their work. But I will try to make some use cases these days and share with you so I can show you specifically what I'm talking about.
 

Maybe I should be sorry for not being as obedient and blindly accepting all board decisions as the word of God, as many on this list.

Can you imagine one moment that people like it?

I know people like it. This is not against people but against conformity. I am saying the board, at some point, may have to reflect on if decisions taken and results obtained aren't masked by "likes" and **may be** raising questions like if we want to compete with Python because with such a crappy eval they have hundreds of libraries used by millions, and we are still discussing why there isn't uninstallers.

 

Understood, what makes me most sad is users almost accepted they cannot do better and if they do, their work will never be integrated by default.

No do better.
Why I started Spec when ther was Glamour. Why Alain was working on Calipso?
I would love that someone comes and tell me: take XX it is super hyper cool UI Builder.

Me too, and by this point we should really ask ourselves why we don't have yet a cool UI Builder.

Hernán

Instead, non-voters decisions discourages users to be rewarded for their creativity, and imposes many others to work free "supporting" tools which were imposed de facto.
 

So again, I cannot stress this enough: Is my job to say no. I know I hurt some people but social development is complicated. 

I do not think I do a bad job :)

Me neither, but you cannot expect conformity from all of us.

Hernán

 

cheers!

Esteban

On 24 Aug 2016, at 09:38, stepharo <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;stepharo@free.fr&#39;);" target="_blank">stepharo@...> wrote:

Hi Hernan

First thanks for your email because we may disagree but we often agree. :) so this is an email for me.

Hi Stef,

Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face.

This is what we want to change with montly videos meeting.

Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.

Like what?
Let us know because we do not

Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid".

This is a pity.
I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;).
And I would like the syndrome to be more human friendly. Thanks for raising this point.

Now two points
    - You should always send a mail to the mailing-list and that we discuss your points.

    - Now what will happen if we all open bugs and none of us works on the open bugs.
So what is the solution for you. I mean it concretely. How to deal with dying

Looking at bugs is really difficult. There are not enough people looking and fixing bugs.

About features.

What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)

It does not really work because engineers are paid for certain task.

Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ?

Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone.
Now we should not see look only at the size. Doing nothing is size zero :)
The point is what are the functionalities delivered.

Three points:
    - what are the key things we want?
            keybinding, settings, cool inspector cool....

    - how many duplicated functionality can we remove:
            for example I want to merge MCDefinitions with Ring with RBDefinition        
            we removed pseudo*
            but this is a lot of work

            The goal is to throw many system when bloc and brick are ready

    - what is the list of things that you would remove?

    - with the bootstrap and all the packages of the image managed with Cargo plus the git management
    we believe that we will be able to manage a set of images with minimal images.
            - this is several years that we are working on this goal.
            Believe me this is the vision document not for the sake of it.

How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them)

    - then you use a jenkins job to produce your image where you unload the tests.

Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?

    No this is not a question of territory. Doru and GT does not do that in that spirit.
    RMOD too. We do something when we think that this is better.
    For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it.
    You see Ghost got changed by denis, Seamless got rewritten from scratch.
   

Who decides? For example (IIRC) TxText and Twisty.

    Igor looked at Twisty seriously and I do not think that it could handle large cobol files.

    (you see funnily denis is doing the same with Seamless - He rewrote it from scratch while
    nick worked on it for several years).

    Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework.
    My team (on our own money if you understand what it means)
    paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
   

The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional?

    No this is not like that.
    If you are better or answer better needs.

There will be anything like PEPs?

    I would love but will people have the energy to implement them?
    I would definitively encourage you as a community to raise points on what you need.

If someone can answer me I think that would be an example of good communication.

    Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens.
    What is clear is that the most important aspects is to continue to communicate. This is why the board is launching
    this initiative and I would love to see it taken by people even for their projects.

Hernán

2016-08-24 1:51 GMT-03:00 stepharo <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;stepharo@free.fr&#39;);" target="_blank">stepharo@...>:

Hi guys

the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.

If you have idea about improving communication around pharo please tell us.


Stef

What we should do is to add an unload method to each of the package manifest of the corresponding projects.

We should make the unload protocol a lot more present.

I will start with Nautilus.

Can you publish the unload process?

Workspace openContents: 'GTPlayground setGTPlaygroundEnabledStatus: false.
" ========== Debuggers ========== "

Nautilus pluginClasses: nil.
SpecDebugger closeAllDebuggers.
GTGenericStackDebugger closeAllDebuggers.
GTGenericStackDebugger setGTDebuggerEnabledStatus: false.

" ========== Miscellany ========== "

GTInspector setGTInspectorEnabledStatus: false.
GTExampleOrganizer stop.
GTEventRecorder cleanUp.
GTEventRecorderSettings cleanUp.
GTSnippets reset.
GTPlayBook reset.
GTPlayBook resetDirectories.
GTSpotter cleanUp.
GTSpotterGlobalShortcut reset.

GlobalIdentifier cleanUp.
Privacy cleanUp.

" ========== QA ========== "
QASettings inspectorPluggin: false.
QASettings spotterPlugin: false.
QAEventCollector unload.
(MCPackage named: ''QualityAssistant'') unload.

" ========== RPackage ========== "
RPackageOrganizer default packageNames
    select: [ :each | each beginsWith: ''GT'' ]
    thenDo: [ :each |
        (MCPackage named: each) unload.
        RPackageOrganizer default unregisterPackageNamed: each.

        " Possibly unnecessary... "

        Smalltalk removeEmptyMessageCategories.
        Smalltalk cleanOutUndeclared.
        Smalltalk fixObsoleteReferences.
        Smalltalk globals flushClassNameCache ].
  
Behavior flushEvents.
Behavior flushObsoleteSubclasses.
SmalltalkImage current resetTools.'

I still have some obsoletes around

AnObsoleteGTSpotterGlobalShortcut .
AnObsoleteQANautilusPlugin .
AnObsoleteGTExampleFinder
AnObsoleteGTExampleOrganizer
AnObsoleteGTSpotterProfiler
AnObsoleteGTEventCollector
AnObsoleteGTExampleNotDefinedRule

Tried to clean but no sucess so far.
 

Respect the freedom of choice for people which is not obligated to love all your tools, by providing an uninstall option (if the tool is not really essential)

I agree about the Unload.... Joseph Pelrine always told me that we are only done when we can
upload and that the system is in a good shape.

You may not know it because I spent days working on configuration of RB and friends
The problems is that it is a hell to keep them up to date (because of our image).
We should have a building process from a seed. Because like that you experiment every single day that you loading script.
Now we did not stress enough the unload of Metacello.


Now you see Pharo cannot be an empty shell.
Because what will happen if we are always listening to someone that does not like something.
Now I strongly encourage you to watch the esug talk about bootstrap because with it and all the work
of Pavel to define configurations for all the part of the system so people will be able to build their solutions when the
official version does not suite their needs.

 

I would love to have the time to invite you, or any GT developer, to work with me just one week with real DNA data, and see how well GT goes...

Please do a skype sharing session with Andrei and Doru. I'm sure that they will love to do it.
So I take your words and urge you do it.
It will help you to get out your frsutration and I'm sure that GT will improve.
So a clear win/win situation.

This is hard for me because I'm sure at this point Andrei and Doru should be angry with me for ciriticizing their work.

No I do not think so :)
I criticized their tools too.

But I will try to make some use cases these days and share with you so I can show you specifically what I'm talking about.

Excellent!

Understood, what makes me most sad is users almost accepted they cannot do better and if they do, their work will never be integrated by default.

No do better.
Why I started Spec when ther was Glamour. Why Alain was working on Calipso?
I would love that someone comes and tell me: take XX it is super hyper cool UI Builder.

Me too, and by this point we should really ask ourselves why we don't have yet a cool UI Builder.

Because nobody did it in a way that we can use it.

One guy worked alone on a private project long time ago. We could not give him any feedback
because he wanted to have it perfect in the first place.
He stoped to work on it because of bad table support.
I looked at it once he opened-source it and you would not like to have the code in Pharo.

Stef

Hernán

Instead, non-voters decisions discourages users to be rewarded for their creativity, and imposes many others to work free "supporting" tools which were imposed de facto.
 

So again, I cannot stress this enough: Is my job to say no. I know I hurt some people but social development is complicated. 

I do not think I do a bad job :)

Me neither, but you cannot expect conformity from all of us.

Hernán

 

cheers!

Esteban

On 24 Aug 2016, at 09:38, stepharo <[hidden email]> wrote:

Hi Hernan

First thanks for your email because we may disagree but we often agree. :) so this is an email for me.

Hi Stef,

Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face.

This is what we want to change with montly videos meeting.

Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.

Like what?
Let us know because we do not

Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid".

This is a pity.
I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;).
And I would like the syndrome to be more human friendly. Thanks for raising this point.

Now two points
    - You should always send a mail to the mailing-list and that we discuss your points.

    - Now what will happen if we all open bugs and none of us works on the open bugs.
So what is the solution for you. I mean it concretely. How to deal with dying

Looking at bugs is really difficult. There are not enough people looking and fixing bugs.

About features.

What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)

It does not really work because engineers are paid for certain task.

Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ?

Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone.
Now we should not see look only at the size. Doing nothing is size zero :)
The point is what are the functionalities delivered.

Three points:
    - what are the key things we want?
            keybinding, settings, cool inspector cool....

    - how many duplicated functionality can we remove:
            for example I want to merge MCDefinitions with Ring with RBDefinition        
            we removed pseudo*
            but this is a lot of work

            The goal is to throw many system when bloc and brick are ready

    - what is the list of things that you would remove?

    - with the bootstrap and all the packages of the image managed with Cargo plus the git management
    we believe that we will be able to manage a set of images with minimal images.
            - this is several years that we are working on this goal.
            Believe me this is the vision document not for the sake of it.

How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them)

    - then you use a jenkins job to produce your image where you unload the tests.

Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?

    No this is not a question of territory. Doru and GT does not do that in that spirit.
    RMOD too. We do something when we think that this is better.
    For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it.
    You see Ghost got changed by denis, Seamless got rewritten from scratch.
   

Who decides? For example (IIRC) TxText and Twisty.

    Igor looked at Twisty seriously and I do not think that it could handle large cobol files.

    (you see funnily denis is doing the same with Seamless - He rewrote it from scratch while
    nick worked on it for several years).

    Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework.
    My team (on our own money if you understand what it means)
    paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
   

The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional?

    No this is not like that.
    If you are better or answer better needs.

There will be anything like PEPs?

    I would love but will people have the energy to implement them?
    I would definitively encourage you as a community to raise points on what you need.

If someone can answer me I think that would be an example of good communication.

    Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens.
    What is clear is that the most important aspects is to continue to communicate. This is why the board is launching
    this initiative and I would love to see it taken by people even for their projects.

Hernán

2016-08-24 1:51 GMT-03:00 stepharo <[hidden email]>:

Hi guys

the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.

If you have idea about improving communication around pharo please tell us.


Stef