December 2010 - Pharo-users

Re: [Pharo-users] Feature requests

by andres

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 <stephane.ducasse(a)inria.fr>: >>> 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, >

Dec. 9, 2010

Re: [Pharo-users] Feature requests

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

Dec. 9, 2010

Re: [Pharo-users] Feature requests

by Geert Claes

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.

Dec. 9, 2010

Re: [Pharo-users] Feature requests

by StÃ©phane Ducasse

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 >

Dec. 9, 2010

Re: [Pharo-users] Feature requests

by 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 <stephane.ducasse(a)inria.fr>: >>> >>> 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. >

Dec. 9, 2010

Re: [Pharo-users] Feature requests

by HernÃ¡n Morales Durand

2010/12/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> 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.

Dec. 9, 2010

Re: [Pharo-users] Feature requests

by andres

> 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

Dec. 8, 2010

Re: [Pharo-users] Feature requests

by George Herolyants

2010/12/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > 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

Dec. 8, 2010

Re: [Pharo-users] Feature requests

by Igor Stasenko

On 8 December 2010 15:46, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 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.

Dec. 8, 2010

Re: [Pharo-users] Feature requests

by 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

Dec. 8, 2010