Hi Stef, 2016-08-25 3:48 GMT-03:00 stepharo <steph...@free.fr>:
> 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 <steph...@free.fr> 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 <steph...@free.fr>: >> >>> 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 >>> >>> >>> >> >> >> > >
