On 24 Aug 2016, at 09:38, stepharo <steph...@free.fr
<mailto: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
<mailto: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
