Feature requests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Feature requests

Andres Fortier-2
Ok, so here goes an attempt of defining how I think feature requests
could be handled and why I think that the meritocracy is not always the
best choice.

UserVoice and similar sites

The idea is to let people ask for features they want in a quick way. I
think my question about native window support could be a good example:
someone ask if a feature exists. If it doesn't, he can just go and
record somewhere "hey, I would like X". If other people also want X they
can put a vote (or more than one) into the feature. Since votes are
finite per user you have to think where are you putting your vote.

Generally the product owner would choose some of the top ranked requests
and decide to implement them. How many requests are selected per release
or what is the criteria for choosing them is up to the product owner
(e.g. you may choose #1 and #3 in the ranking, since #2 may be too
complex for a given release). I guess that as long as the rules are
clear (e.g. choose at least 1 feature request from the top five or
whatever the dev team feels is ok for them) things would run smooth.

Of course you can consider alternatives, like giving contributors more
votes to encourage participation, get an extra vote for each bug you
found, etc.

Advantages: Its easy, it welcomes newcomers, it allows to re-think your
vote or change it if you see that someone posted a feature that you also
require, it allows the dev team to measure the user's expectations.
Disadvantages: if you don't have enough population the requests may not
reflect the real community needs, as a dev team you may end up
implementing something you don't consider relevant.

About Meritocracy

While I understand the idea behind "first do something, then ask for
something" I don't think it is always the best choice. For someone to
commit to do something he must feel he is inside a community, and that
takes some time. Of course I'm not saying that someone who just
downloaded Pharo should dictate what will be included in the next
release, I'm just saying that his voice shouldn't be banned because he
hasn't yet contributed. And I am convinced that it is more likely to
have a newcomer commited to a cause if you listen to him rather than if
you say "first do something, then I may listen to your requests".

But what concerned me the most was this:

The only influence we deeply understand is ***Contributions*** with
either videos, pdf, ads, promotion actions or ST code.
So if you want something to happen for real in pharo then you should
consider how you can make this happens.

So how do you measure someone's contribution and the rights he has?
Talking about pharo at my university counts for changing a line of code,
writing some slides for a method, creating a bunch of screencasts for
some classes? Also, contributing to Smalltalk in general counts as a
contribution to Pharo? Up to what extent? And if I contributed and you
never knew? Should I present my credentials asking for your
reconsideration? My point is that, while contributions are fine and I
also like for people to give in return for what they received, it is
sometimes hard to measure and be fair to everybody. As you explained it
seems that the decision rests in the subjective view of the core
developers. That model is of course a valid one, I just consider it is
not how healthy communities are built.

Best regards,
Andrés

Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

hernanmd
Hi,

Thanks for bringing this topic to the list. I like the proposal, but I
don't like it in the sense that these kind of mails are "good idea"
which requires work and we-all-are-always-busy. Here is what I've
seen: This is a distributed community. We may learn from other open
source software communities. How they specify revisions and
improvements, see for example:

Community    Formal Process
Python    ->    PEP (http://www.python.org/dev/peps/)
Jabber     ->    XEP (http://xmpp.org/extensions/)
Plone      ->    PLIP (http://plone.org/documentation/glossary/plip)

In Python this process includes as activities:
1) Documentation
2) Discussion (which is the most important to keep a high rate of participation)
3) Implementation

Maybe that's a valid path too. I read the IRC meeting yesterday. I was
suprised in the sense almost no comments were made to what we need to
learn about the current Pharo users, about the energy spent in
peer-reviewing code or proposals, the division of labor, how many
active contributors have the Core or Dev packages, why some of them
abandoned or joined, etc.
IMHO sooner or later, the core team should have a better view of
social dynamics here (I know it requires hard work but there are
social scientists out there!). How participants participate, to
understand the complexities of motivation, involvement, roles, group
calibration, etc. Meta-discussing about our participation is not very
comfortable or somewhat controversial, because exposes hidden
structures of power or implicit social rules. Which are inevitable.
But you will gain insight distinguishing between:

Proposals
Evaluations
Clarifications
Synthesis
Coordination
Decisions

and see the most common patterns

Proposals -> Evaluations -> Agreement/Disagreement
Clarifications -> Clarifications
Synthesis -> Agreement/Proposal
Coordination -> Coordination
Decisions -> Coordination

I know Andrés did a lot of good work in and for Smalltalk, he
shouldn't need to present any credentials here. And besides there must
be a nice way to make people listened and to considerate their claims.
Cheers.

2010/12/7 andres <[hidden email]>:

> Ok, so here goes an attempt of defining how I think feature requests could
> be handled and why I think that the meritocracy is not always the best
> choice.
>
> UserVoice and similar sites
>
> The idea is to let people ask for features they want in a quick way. I think
> my question about native window support could be a good example: someone ask
> if a feature exists. If it doesn't, he can just go and record somewhere
> "hey, I would like X". If other people also want X they can put a vote (or
> more than one) into the feature. Since votes are finite per user you have to
> think where are you putting your vote.
>
> Generally the product owner would choose some of the top ranked requests and
> decide to implement them. How many requests are selected per release or what
> is the criteria for choosing them is up to the product owner (e.g. you may
> choose #1 and #3 in the ranking, since #2 may be too complex for a given
> release). I guess that as long as the rules are clear (e.g. choose at least
> 1 feature request from the top five or whatever the dev team feels is ok for
> them) things would run smooth.
>
> Of course you can consider alternatives, like giving contributors more votes
> to encourage participation, get an extra vote for each bug you found, etc.
>
> Advantages: Its easy, it welcomes newcomers, it allows to re-think your vote
> or change it if you see that someone posted a feature that you also require,
> it allows the dev team to measure the user's expectations.
> Disadvantages: if you don't have enough population the requests may not
> reflect the real community needs, as a dev team you may end up implementing
> something you don't consider relevant.
>
> About Meritocracy
>
> While I understand the idea behind "first do something, then ask for
> something" I don't think it is always the best choice. For someone to commit
> to do something he must feel he is inside a community, and that takes some
> time. Of course I'm not saying that someone who just downloaded Pharo should
> dictate what will be included in the next release, I'm just saying that his
> voice shouldn't be banned because he hasn't yet contributed. And I am
> convinced that it is more likely to have a newcomer commited to a cause if
> you listen to him rather than if you say "first do something, then I may
> listen to your requests".
>
> But what concerned me the most was this:
>
> The only influence we deeply understand is ***Contributions*** with either
> videos, pdf, ads, promotion actions or ST code.
> So if you want something to happen for real in pharo then you should
> consider how you can make this happens.
>
> So how do you measure someone's contribution and the rights he has? Talking
> about pharo at my university counts for changing a line of code, writing
> some slides for a method, creating a bunch of screencasts for some classes?
> Also, contributing to Smalltalk in general counts as a contribution to
> Pharo? Up to what extent? And if I contributed and you never knew? Should I
> present my credentials asking for your reconsideration? My point is that,
> while contributions are fine and I also like for people to give in return
> for what they received, it is sometimes hard to measure and be fair to
> everybody. As you explained it seems that the decision rests in the
> subjective view of the core developers. That model is of course a valid one,
> I just consider it is not how healthy communities are built.
>
> Best regards,
> Andrés
>
>



--
Hernán Morales
Information Technology Manager,
Institute of Veterinary Genetics.
National Scientific and Technical Research Council (CONICET).
La Plata (1900), Buenos Aires, Argentina.
Telephone: +54 (0221) 421-1799.
Internal: 422
Fax: 425-7980 or 421-1799.

Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Stéphane Ducasse
>
> I know Andrés did a lot of good work in and for Smalltalk, he
> shouldn't need to present any credentials here. And besides there must
> be a nice way to make people listened and to considerate their claims.

I know him too and this is not the problem of trust or achievement as a programmer.
We consider claim and expectations this is why we sent calls in the past.

Now the key question is: is it productive to discuss features if by construction we know that we will not have
the manpower to do something?
We can dream and talk but at the end of the day if we say ok it costs 4 man months and changing all the vms (which I would love to see happening).

I have a huge wish list, believe me and the result is gorgeous now the only thing that I can do
is to take one of the item and beat it to death and doing it and go to the next one. And I frustrate a lot
because these are a lot of tiny steps.

Stef



Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Igor Stasenko
On 8 December 2010 15:46, Stéphane Ducasse <[hidden email]> wrote:

>>
>> I know Andrés did a lot of good work in and for Smalltalk, he
>> shouldn't need to present any credentials here. And besides there must
>> be a nice way to make people listened and to considerate their claims.
>
> I know him too and this is not the problem of trust or achievement as a programmer.
> We consider claim and expectations this is why we sent calls in the past.
>
> Now the key question is: is it productive to discuss features if by construction we know that we will not have
> the manpower to do something?
> We can dream and talk but at the end of the day if we say ok it costs 4 man months and changing all the vms (which I would love to see happening).
>
> I have a huge wish list, believe me and the result is gorgeous now the only thing that I can do
> is to take one of the item and beat it to death and doing it and go to the next one. And I frustrate a lot
> because these are a lot of tiny steps.
>

Amen.

The better native windows support is pending in my head for 2 years (i
think). At least that was a first time when i first thought about it
and took some
effort to experiment with it and implemented a prototypes.
But then i left it, because i had other things to do, and because
there was not much interest from people to do that anyways :)

So, really, if there's anyone who willing to invest good lump of money
in it, it could be done in multiple months. Otherwise, the best what
you can do
is to check/ask about the current state of art then form a strategy
and step by step do things which will bring the day when you have your
feature request fulfilled closer.

> Stef
>


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

George Herolyants-3
In reply to this post by Stéphane Ducasse
2010/12/8 Stéphane Ducasse <[hidden email]>:
> Now the key question is: is it productive to discuss features if by construction we know that we will not have
> the manpower to do something?

I think it is. Who knows, maybe such a wishlist could influence
somebody to make a contribution or some research?

George

Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Andres Fortier-2
In reply to this post by Stéphane Ducasse
> Now the key question is: is it productive to discuss features if by construction we know that we will not have
> the manpower to do something?

I think that if you never put the list in public you will never know; if
you have your list and I have mine and so does everybody we will always
feel like we are the only ones who want that. If we find out that 20 o
30 people want the same thing then maybe we can find a way of making it
happen.

> We can dream and talk but at the end of the day if we say ok it costs 4 man months and changing all the vms (which I would love to see happening).

I think that there are a lot of things out there that don't mean that
you have to change the VMs.

Andrés

Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

hernanmd
In reply to this post by Stéphane Ducasse
2010/12/8 Stéphane Ducasse <[hidden email]>:

>>
>> I know Andrés did a lot of good work in and for Smalltalk, he
>> shouldn't need to present any credentials here. And besides there must
>> be a nice way to make people listened and to considerate their claims.
>
> I know him too and this is not the problem of trust or achievement as a programmer.
> We consider claim and expectations this is why we sent calls in the past.
>
> Now the key question is: is it productive to discuss features if by construction we know that we will not have
> the manpower to do something?

Considering the extreme and embarrassing success of, for example,
Python (even with their crappy syntax and methodologies) over
Smalltalk, I think yes it is productive to learn from succesfully
software projects.

What's wrong with the revisions and improvements process described in
my previous mail? Why nobody considerate it?

See for example:

What is a PEP?
==============

PEP stands for Python Enhancement Proposal.  A PEP is a design
document providing information to the Python community, or describing
a new feature for Python or its processes or environment.  The PEP
should provide a concise technical specification of the feature and a
rationale for the feature.

We intend PEPs to be the primary mechanisms for proposing new
features, for collecting community input on an issue, and for
documenting the design decisions that have gone into Python.  The PEP
author is responsible for building consensus within the community and
documenting dissenting opinions.

Because the PEPs are maintained as text files in a versioned
repository, their revision history is the historical record of the
feature proposal

(from http://svn.python.org/projects/peps/trunk/pep-0001.txt)

> We can dream and talk but at the end of the day if we say ok it costs 4 man months and changing all the vms (which I would love to see happening).
>
> I have a huge wish list, believe me and the result is gorgeous now the only thing that I can do
> is to take one of the item and beat it to death and doing it and go to the next one. And I frustrate a lot
> because these are a lot of tiny steps.
>

Ok, what I'm saying is why don't start organizing the proposals,
evaluations, coordination, decisions, etc. and then the people will
come.
Cheers,

--
Hernán Morales
Information Technology Manager,
Institute of Veterinary Genetics.
National Scientific and Technical Research Council (CONICET).
La Plata (1900), Buenos Aires, Argentina.
Telephone: +54 (0221) 421-1799.
Internal: 422
Fax: 425-7980 or 421-1799.

Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Stéphane Ducasse
I know what is a PEP believe me. We tried that in Squeak long time ago.

Stef

On Dec 9, 2010, at 2:04 AM, Hernán Morales Durand wrote:

> 2010/12/8 Stéphane Ducasse <[hidden email]>:
>>>
>>> I know Andrés did a lot of good work in and for Smalltalk, he
>>> shouldn't need to present any credentials here. And besides there must
>>> be a nice way to make people listened and to considerate their claims.
>>
>> I know him too and this is not the problem of trust or achievement as a programmer.
>> We consider claim and expectations this is why we sent calls in the past.
>>
>> Now the key question is: is it productive to discuss features if by construction we know that we will not have
>> the manpower to do something?
>
> Considering the extreme and embarrassing success of, for example,
> Python (even with their crappy syntax and methodologies) over
> Smalltalk, I think yes it is productive to learn from succesfully
> software projects.
>
> What's wrong with the revisions and improvements process described in
> my previous mail? Why nobody considerate it?
>
> See for example:
>
> What is a PEP?
> ==============
>
> PEP stands for Python Enhancement Proposal.  A PEP is a design
> document providing information to the Python community, or describing
> a new feature for Python or its processes or environment.  The PEP
> should provide a concise technical specification of the feature and a
> rationale for the feature.
>
> We intend PEPs to be the primary mechanisms for proposing new
> features, for collecting community input on an issue, and for
> documenting the design decisions that have gone into Python.  The PEP
> author is responsible for building consensus within the community and
> documenting dissenting opinions.
>
> Because the PEPs are maintained as text files in a versioned
> repository, their revision history is the historical record of the
> feature proposal
>
> (from http://svn.python.org/projects/peps/trunk/pep-0001.txt)
>
>> We can dream and talk but at the end of the day if we say ok it costs 4 man months and changing all the vms (which I would love to see happening).
>>
>> I have a huge wish list, believe me and the result is gorgeous now the only thing that I can do
>> is to take one of the item and beat it to death and doing it and go to the next one. And I frustrate a lot
>> because these are a lot of tiny steps.
>>
>
> Ok, what I'm saying is why don't start organizing the proposals,
> evaluations, coordination, decisions, etc. and then the people will
> come.
> Cheers,
>
> --
> Hernán Morales
> Information Technology Manager,
> Institute of Veterinary Genetics.
> National Scientific and Technical Research Council (CONICET).
> La Plata (1900), Buenos Aires, Argentina.
> Telephone: +54 (0221) 421-1799.
> Internal: 422
> Fax: 425-7980 or 421-1799.
>


Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Stéphane Ducasse
In reply to this post by Andres Fortier-2
sure so express yourself but if you want an impact you know what should be done.

On Dec 8, 2010, at 10:17 PM, andres wrote:

>> Now the key question is: is it productive to discuss features if by construction we know that we will not have the manpower to do something?
>
> I think that if you never put the list in public you will never know; if you have your list and I have mine and so does everybody we will always feel like we are the only ones who want that. If we find out that 20 o 30 people want the same thing then maybe we can find a way of making it happen.
>
>> We can dream and talk but at the end of the day if we say ok it costs 4 man months and changing all the vms (which I would love to see happening).
>
> I think that there are a lot of things out there that don't mean that you have to change the VMs.
>
> Andrés
>


Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Geert Claes
Administrator
In reply to this post by Andres Fortier-2
Hi Andres,  I understood from your previous post that you are in favour of a crowdsourcing/brainstorming approach like UserVoice, IdeaTorrent (OLPC, Ubuntu ...), IdeaScale,  etc, but please do keep in mind that the Pharo community is still a very small community that relies on a relatively small number of contributors.  From the Pharo-Project.org website: "All the discussions about Pharo's direction are open and occur on the mailing list. Everything is transparent and will remain so." so ideas and suggestions from both seasoned Pharoers as well as newcomers are always welcome and nobody's voice is ever or has ever been banned.

You mentioned in your post as disadvantages of a voting system that "if you don't have enough population the requests may not reflect the real community needs, as a dev team you may end up implementing something you don't consider relevant.".  The problem is not necessarily the voting aspect, but the fact that the Pharo project doesn't really have a "dev-team" as such.  The Pharo project consists of a number of contributors who fix and add things mainly because they want and need these things themselves and in doing so contribute to a better Pharo system.

I am a bit confused as to what exactly you are suggesting because if (for argument's sake) Pharo were to setup an IdeaTorrent.  Lets say certain ideas receive a number of votes and as a result they are then considered "popular".  Since the Pharo project does not have a real "dev-team" that can be told what to do, who will be implementing these "popular" ideas?  What if contributors (who sacrifice their own free-time) choose to fix or implement valuable aspects (which did not receive as many votes) and ignore the most "popular" ideas?   As a side-note: giving people more votes (or allowing to vote against ideas) has a history of causing a lot of drama and add no value :)

When you were talking about what "rights" anyone has in the Pharo community, I think the best way to put it (feel free to correct me) is probably that "nobody has the right to tell someone else what to do or not to do" and that "everybody has the right and is encouraged to contribute".  The only time the Pharo board will step in is when the community can't reach a consensus.

Anyhow, nobody is saying that your idea of a voting system is bad, its just that for such a system to work, the project would need the resources to tackle these top ideas and as it stand this is unfortunately not the case.  Pharo has come a long way in two years and its still moving strong :)

Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Stéphane Ducasse
Well said.
I would love to be in position to ask the community for what feature one single developer payed by the community
would focus on.

We do not have this luxury.

Stef

On Dec 9, 2010, at 11:48 AM, Geert Claes wrote:

>
> Hi Andres,  I understood from your previous post that you are in favour of a
> crowdsourcing/brainstorming approach like UserVoice, IdeaTorrent (OLPC,
> Ubuntu ...), IdeaScale,  etc, but please do keep in mind that the Pharo
> community is still a very small community that relies on a relatively small
> number of contributors.  From the Pharo-Project.org website: "All the
> discussions about Pharo's direction are open and occur on the mailing list.
> Everything is transparent and will remain so." so ideas and suggestions from
> both seasoned Pharoers as well as newcomers are always welcome and nobody's
> voice is ever or has ever been banned.
>
> You mentioned in your post as disadvantages of a voting system that "if you
> don't have enough population the requests may not reflect the real community
> needs, as a dev team you may end up implementing something you don't
> consider relevant.".  The problem is not necessarily the voting aspect, but
> the fact that the Pharo project doesn't really have a "dev-team" as such.
> The Pharo project consists of a number of contributors who fix and add
> things mainly because they want and need these things themselves and in
> doing so contribute to a better Pharo system.
>
> I am a bit confused as to what exactly you are suggesting because if (for
> argument's sake) Pharo were to setup an IdeaTorrent.  Lets say certain ideas
> receive a number of votes and as a result they are then considered
> "popular".  Since the Pharo project does not have a real "dev-team" that can
> be told what to do, who will be implementing these "popular" ideas?  What if
> contributors (who sacrifice their own free-time) choose to fix or implement
> valuable aspects (which did not receive as many votes) and ignore the most
> "popular" ideas?   As a side-note: giving people more votes (or allowing to
> vote against ideas) has a history of causing a lot of drama and add no value
> :)
>
> When you were talking about what "rights" anyone has in the Pharo community,
> I think the best way to put it (feel free to correct me) is probably that
> "nobody has the right to tell someone else what to do or not to do" and that
> "everybody has the right and is encouraged to contribute".  The only time
> the Pharo board will step in is when the community can't reach a consensus.
>
> Anyhow, nobody is saying that your idea of a voting system is bad, its just
> that for such a system to work, the project would need the resources to
> tackle these top ideas and as it stand this is unfortunately not the case.
> Pharo has come a long way in two years and its still moving strong :)
>
>
> --
> View this message in context: http://forum.world.st/Feature-requests-tp3077333p3079927.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Andres Fortier-2
In reply to this post by hernanmd
I don't know if feature requests, PEPs or which other scheme may be the
better fit. I do believe that having a way of documenting feature
requests would be useful. But I also think that the board should agree
with that for having something positive going on, and that doesn't seem
to be the case. So I guess that's pretty much it.

Cheers,
Andrés

Hernán Morales Durand escribió:

> 2010/12/8 Stéphane Ducasse <[hidden email]>:
>>> I know Andrés did a lot of good work in and for Smalltalk, he
>>> shouldn't need to present any credentials here. And besides there must
>>> be a nice way to make people listened and to considerate their claims.
>> I know him too and this is not the problem of trust or achievement as a programmer.
>> We consider claim and expectations this is why we sent calls in the past.
>>
>> Now the key question is: is it productive to discuss features if by construction we know that we will not have
>> the manpower to do something?
>
> Considering the extreme and embarrassing success of, for example,
> Python (even with their crappy syntax and methodologies) over
> Smalltalk, I think yes it is productive to learn from succesfully
> software projects.
>
> What's wrong with the revisions and improvements process described in
> my previous mail? Why nobody considerate it?
>
> See for example:
>
> What is a PEP?
> ==============
>
> PEP stands for Python Enhancement Proposal.  A PEP is a design
> document providing information to the Python community, or describing
> a new feature for Python or its processes or environment.  The PEP
> should provide a concise technical specification of the feature and a
> rationale for the feature.
>
> We intend PEPs to be the primary mechanisms for proposing new
> features, for collecting community input on an issue, and for
> documenting the design decisions that have gone into Python.  The PEP
> author is responsible for building consensus within the community and
> documenting dissenting opinions.
>
> Because the PEPs are maintained as text files in a versioned
> repository, their revision history is the historical record of the
> feature proposal
>
> (from http://svn.python.org/projects/peps/trunk/pep-0001.txt)
>
>> We can dream and talk but at the end of the day if we say ok it costs 4 man months and changing all the vms (which I would love to see happening).
>>
>> I have a huge wish list, believe me and the result is gorgeous now the only thing that I can do
>> is to take one of the item and beat it to death and doing it and go to the next one. And I frustrate a lot
>> because these are a lot of tiny steps.
>>
>
> Ok, what I'm saying is why don't start organizing the proposals,
> evaluations, coordination, decisions, etc. and then the people will
> come.
> Cheers,
>

Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Andres Fortier-2
In reply to this post by Geert Claes
Hi Geert,
               thanks for your detailed mail. I didn't (still don't)
know the exact size of the community. I understand that not having a
stable dev-team is definitely a problem and may even forbid things like
a commitment to solve "popular" feature requests per release. Yet I'm
convinced that knowing what your user's want should be a central part of
an open-source project like Pharo, where you are actually building a
platform for other people to use and exploit. Most successful
open-source projects are those that can built a strong community around
them and from my point of view knowing what the community wants is an
important step. I believe that if the message is "we are listening to
what you want and we will try to achieve it" instead of "do it yourself"
you have more chances of creating a healthy community.

Cheers,
Andrés

Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Mariano Martinez Peck
In reply to this post by George Herolyants-3


On Wed, Dec 8, 2010 at 9:46 PM, George Herolyants <[hidden email]> wrote:
2010/12/8 Stéphane Ducasse <[hidden email]>:
> Now the key question is: is it productive to discuss features if by construction we know that we will not have
> the manpower to do something?

I think it is. Who knows, maybe such a wishlist could influence
somebody to make a contribution or some research?

+1

I think a wishlist is worth it even if there won't be manpower at that moment.
Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Stéphane Ducasse
In reply to this post by Andres Fortier-2

> I don't know if feature requests, PEPs or which other scheme may be the better fit. I do believe that having a way of documenting feature requests would be useful. But I also think that the board should agree with that for having something positive going on, and that doesn't seem to be the case. So I guess that's pretty much it.

andres

we are not against PEPs, we are just frustrated that nothing will come out except if I win to the europe lotery several billion euros and I invest in Pharo (but I do not buy tickets so chances are low).

Stef

>
> Cheers,
> Andrés
>
> Hernán Morales Durand escribió:
>> 2010/12/8 Stéphane Ducasse <[hidden email]>:
>>>> I know Andrés did a lot of good work in and for Smalltalk, he
>>>> shouldn't need to present any credentials here. And besides there must
>>>> be a nice way to make people listened and to considerate their claims.
>>> I know him too and this is not the problem of trust or achievement as a programmer.
>>> We consider claim and expectations this is why we sent calls in the past.
>>>
>>> Now the key question is: is it productive to discuss features if by construction we know that we will not have
>>> the manpower to do something?
>> Considering the extreme and embarrassing success of, for example,
>> Python (even with their crappy syntax and methodologies) over
>> Smalltalk, I think yes it is productive to learn from succesfully
>> software projects.
>> What's wrong with the revisions and improvements process described in
>> my previous mail? Why nobody considerate it?
>> See for example:
>> What is a PEP?
>> ==============
>> PEP stands for Python Enhancement Proposal.  A PEP is a design
>> document providing information to the Python community, or describing
>> a new feature for Python or its processes or environment.  The PEP
>> should provide a concise technical specification of the feature and a
>> rationale for the feature.
>> We intend PEPs to be the primary mechanisms for proposing new
>> features, for collecting community input on an issue, and for
>> documenting the design decisions that have gone into Python.  The PEP
>> author is responsible for building consensus within the community and
>> documenting dissenting opinions.
>> Because the PEPs are maintained as text files in a versioned
>> repository, their revision history is the historical record of the
>> feature proposal
>> (from http://svn.python.org/projects/peps/trunk/pep-0001.txt)
>>> We can dream and talk but at the end of the day if we say ok it costs 4 man months and changing all the vms (which I would love to see happening).
>>>
>>> I have a huge wish list, believe me and the result is gorgeous now the only thing that I can do
>>> is to take one of the item and beat it to death and doing it and go to the next one. And I frustrate a lot
>>> because these are a lot of tiny steps.
>>>
>> Ok, what I'm saying is why don't start organizing the proposals,
>> evaluations, coordination, decisions, etc. and then the people will
>> come.
>> Cheers,
>


Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Stéphane Ducasse
In reply to this post by Andres Fortier-2
so here is my whislist in no order.

        - multiwindowing system
        - native mashup of native elements by os for building widgets
        - new ui framework (with decent coordinate system) a cool sexy widget set (MVP behind).
        - vm callable as dll
        - bootstrappable
        - distributions + build servers + validated packages
        - better code browsers and tools
        - pretty print as you type
        - cairo backend or opensvg like rendering
        - faster/cleaner monticello
        - new filesystem
        - module system
        - new mop
        - UIbuilder and interpreter
        - good RMI
        - better JIT
        - cleaner VM code
        - faster system
        - good connection with C libraries
        - clean and extensible event system
        - remote debugger
        - better compiler
        - cross compilation
        - better documentation with example
        - 100% test coverage
        - better library for
                connection to database
                https
                XML handling
                web services gluing and extracting info
                https support
                network
        - widget for seaside
        - scaffolding for CRUD in Seaside
        - persistency solutions
        - OODMs
        - ERP in Smalltalk
        - ...

So ok add yours.
Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Igor Stasenko
10 man-years :)


On 9 December 2010 22:24, Stéphane Ducasse <[hidden email]> wrote:

> so here is my whislist in no order.
>
>        - multiwindowing system
>        - native mashup of native elements by os for building widgets
>        - new ui framework (with decent coordinate system) a cool sexy widget set (MVP behind).
>        - vm callable as dll
>        - bootstrappable
>        - distributions + build servers + validated packages
>        - better code browsers and tools
>        - pretty print as you type
>        - cairo backend or opensvg like rendering
>        - faster/cleaner monticello
>        - new filesystem
>        - module system
>        - new mop
>        - UIbuilder and interpreter
>        - good RMI
>        - better JIT
>        - cleaner VM code
>        - faster system
>        - good connection with C libraries
>        - clean and extensible event system
>        - remote debugger
>        - better compiler
>        - cross compilation
>        - better documentation with example
>        - 100% test coverage
>        - better library for
>                connection to database
>                https
>                XML handling
>                web services gluing and extracting info
>                https support
>                network
>        - widget for seaside
>        - scaffolding for CRUD in Seaside
>        - persistency solutions
>        - OODMs
>        - ERP in Smalltalk
>        - ...
>
> So ok add yours.
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Stefan Marr-4

On 09 Dec 2010, at 22:30, Igor Stasenko wrote:

> 10 man-years :)
And thats alone for the better JIT/VM ;)

>
>
> On 9 December 2010 22:24, Stéphane Ducasse <[hidden email]> wrote:
>> so here is my whislist in no order.
>>
>>        - multiwindowing system
>>        - native mashup of native elements by os for building widgets
>>        - new ui framework (with decent coordinate system) a cool sexy widget set (MVP behind).
>>        - vm callable as dll
>>        - bootstrappable
>>        - distributions + build servers + validated packages
>>        - better code browsers and tools
>>        - pretty print as you type
>>        - cairo backend or opensvg like rendering
>>        - faster/cleaner monticello
>>        - new filesystem
>>        - module system
>>        - new mop
>>        - UIbuilder and interpreter
>>        - good RMI
>>        - better JIT
>>        - cleaner VM code
>>        - faster system
>>        - good connection with C libraries
>>        - clean and extensible event system
>>        - remote debugger
>>        - better compiler
>>        - cross compilation
>>        - better documentation with example
>>        - 100% test coverage
>>        - better library for
>>                connection to database
>>                https
>>                XML handling
>>                web services gluing and extracting info
>>                https support
>>                network
>>        - widget for seaside
>>        - scaffolding for CRUD in Seaside
>>        - persistency solutions
>>        - OODMs
>>        - ERP in Smalltalk
>>        - ...
>>
>> So ok add yours.
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

Andres Fortier-2
In reply to this post by Stéphane Ducasse
If you had actually considered what has been written in this thread,
then you'll realize that throwing a bunch of items in an e-mail has
nothing to do with feature requests. I find quite contradictory that one
of your main arguments is about not having enough contributors and yet
take that attitude instead of getting something positive out of the
initiative. But I guess I must be wrong, that surely works, It's just me
that doesn't understand how.

Andrés


Stéphane Ducasse escribió:

> so here is my whislist in no order.
>
> - multiwindowing system
> - native mashup of native elements by os for building widgets
> - new ui framework (with decent coordinate system) a cool sexy widget set (MVP behind).
> - vm callable as dll
> - bootstrappable
> - distributions + build servers + validated packages
> - better code browsers and tools
> - pretty print as you type
> - cairo backend or opensvg like rendering
> - faster/cleaner monticello
> - new filesystem
> - module system
> - new mop
> - UIbuilder and interpreter
> - good RMI
> - better JIT
> - cleaner VM code
> - faster system
> - good connection with C libraries
> - clean and extensible event system
> - remote debugger
> - better compiler
> - cross compilation
> - better documentation with example
> - 100% test coverage
> - better library for
> connection to database
> https
> XML handling
> web services gluing and extracting info
> https support
> network
> - widget for seaside
> - scaffolding for CRUD in Seaside
> - persistency solutions
> - OODMs
> - ERP in Smalltalk
> - ...
>
> So ok add yours.
>

Reply | Threaded
Open this post in threaded view
|

Re: Feature requests

James Ashley
On Thu, Dec 9, 2010 at 7:38 PM, andres <[hidden email]> wrote:
> If you had actually considered what has been written in this thread, then
> you'll realize that throwing a bunch of items in an e-mail has nothing to do
> with feature requests. I find quite contradictory that one of your main
> arguments is about not having enough contributors and yet take that attitude
> instead of getting something positive out of the initiative. But I guess I
> must be wrong, that surely works, It's just me that doesn't understand how.

As a complete smalltalk n00b, I just don't have a dog in this "fight."
Here's the summary of what I've seen in this thread (my apologies for
the missing accents, like most Americans, I'm an asshole):

Andres: Wouldn't it be great if we let the community contribute and
request features?!
Stephane: Been there, tried that. Doesn't work.
Andres: But let's try it again!
Stephane: Fine. Here's my wish-list. Any suggestions about how to pay for it?
Andres: Quit being a jerk.

Looking in from the outside, I can see that both of you are correct.
This is open source's biggest strength and its greatest weakness.

Get involved. Do something that makes life better for everyone else.
Quit expecting someone else to solve your problems for you.

Put together a project on github, or sourceforge, or assembla, or
wherever. Get people who love a project and want to contribute. Or
just provide contributions yourself.

Quit talking, quit planning, and actually *do* something.  Odds are,
the people who are already involved in the project know what needs to
be done...they're just busy with things like Real Life and don't have
time.

> Andrés

And, yes. This was really directed more toward me than anyone else.

-- James

12