Now I will try to be more positive. 2016-08-24 4:38 GMT-03:00 stepharo <steph...@free.fr>:
> 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. > Good initiative, thanks! > 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 > I don't get why we don't have more discussions about end-developer tools : XML, i18n, GIS, simulation & expert systems, big data, reporting... > 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. > > I think you could implement some reward system for devs with more bug fixes: Interviews, consortium membership, maybe voting on some issues...? > 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? > > To me there a couple of things which must have two versions (considering we lack a sub-image where to do image repairing). - Inspector: -- One cool (this seems will ever be GT) -- One bullet-proof very very limited (to repair GT when broken, or minimal image) - System Browser -- One cool (like Nautilus) -- One standard (to not have an unusable image if the cool one gets broken) - 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. > > I see, never tried Jenkins for real (but maybe rethorical question: is that true users need all the Tests in the image? To test a package like Graphics-Test?) > 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). > > > So the money decides :) > 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. > > I would write a "PEP" if someone from the board seriously considers to review it and integrate it (or not) with a clear communication. > 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. > > Thank you Stef for raising this space to consider both good and uncomfortable things. I believe one day we -pharo users- have to take the world and show what's happening here. Time passes and we have an unique chance of changing the world through Pharo, our beloved self-convinced textual-relational world. Pharo technology is designed to push limits, so let's do things differently once. One thing that could change the world: Let's browse Java/Python code directly from Nautilus. 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 > > >