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
>
>
>
