December 2010 - Pharo-users

Re: [Pharo-users] Money AND Feature requests

by James Ashley

On Sat, Dec 11, 2010 at 7:16 AM, Geoffroy Couprie <geo.couprie(a)gmail.com> wrote: > Hello, > > On Sat, Dec 11, 2010 at 10:20 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Good! >> Tell us what architecture we can use for that. I should find some time to build a association of loi 1901 and get a paypal account for pharo. >> > > You should take a look at Flattr for donations. I think the basics might be a good idea, but flattr just doesn't seem like a useful/viable choice to me. They're way too vague about how much of the money they keep, and it's really set up as a subscription service (last time I checked, anyway). It's just that you get to decide how you distribute your $x per month (as long as you stay on top of things and make that decision every month). > Also, in case some > want to donate for specific feature, there are crowdfunding solutions > like kickstarter. Kickstarter sounds like it might be a *much* better choice for this sort of thing. I'm not sure how good it would be for on-going projects, though. e.g. "You paid $50 last month to have Geoffrey spend a month working on feature x. He estimates that he's 75% done. Will you spend $12.50 to let him spend another week on it?" Just my $0.02. -- James

Dec. 11, 2010

Re: [Pharo-users] Money AND Feature requests

by laurent laffont

Yes I think it's good to have a real Pharo entity / status / association loi 1901. For architecture, as AndrÃ©s said he/we can set a UserVoice. For raising money http://pledgie.com/. As for Flattr the idea is good but it seems to raise only little money actually (feedback from pharobyexample and pharocasts. But we haven't tried to encourage people to donate). Laurent. On Sat, Dec 11, 2010 at 10:20 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Dec 10, 2010, at 11:00 PM, laurent laffont wrote: > > > Thinking again about this idea of voting system for features we would > like to see in Pharo. > > > > I won't pay 10 euros / month for someone to develop full time on Pharo on > what I do not control (may not be the best words to explain my feelings :) > > > > But I'm ready to give 30 to 50 euros to raise money to develop the most > wanted feature from a voting system. This give more visibility. > > > > It's easier to make a one shot donation than give XXeuros/month. > > Good! > Tell us what architecture we can use for that. I should find some time to > build a association of loi 1901 and get a paypal account for pharo. > > > > > > > So one way to achieve this is to set up a voting system AND associated > raising money system to develop the most wanted feature for one month. > > > > Another way is to pick the most wanted feature for Google Summer of code. > > Don't expect anything from it > > > With enough money one can stop his work for one month and develop > exclusively for Pharo. If it's too hard to raise money for one month, we can > try 15 days. I've seen that some great developers can do fantastic stuff in > 15 days when he loves it :) > > > > Laurent Laffont > > > > On Fri, Dec 10, 2010 at 3:29 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > > On 10 December 2010 13:32, Davorin Rusevljan > > <davorin.rusevljan(a)gmail.com> wrote: > > > On Fri, Dec 10, 2010 at 1:06 PM, Alan Rodas <alanrodas(a)gmail.com> > wrote: > > >> I'm relatively new to Pharo, maybe this has been tried before, but > what > > >> about a forum where the ideas are published. > > >> Each idea could be a thread in the forum, and the people that would > like to > > >> contribute may comment there. What it may be interesting is that the > whole > > >> discussion about an idea could live in the thread, and you can keep > track of > > >> old discussions and the state of a feature. > > >> If you keep your ideas for yourself, and you cannot implement > something by > > >> your own, that idea will die there. If you allow people to comment on > ideas, > > >> maybe two or more people have the same, and they can start working on > > >> it together. A forum allows for contacting people, and sharing, and, > in that > > >> way, maybe the community will grow (Some developers feel they can do > > >> something because they don't have the time to do it by their own, or > they > > >> don't have the skills, but they can help to a dev team that share the > same > > >> goals.) > > >> > > >> > > >> Is just a thought. > > >> If you did it before and didn't work, my apologies. > > > > > > Well, those are all nice thoughts. I am also relatively new to Pharo > > > though, I am with Smalltalk for quite a long time. In my humble > > > opinion, while both are always nice to have, at this stage Pharo, much > > > needs more hands willing to do the work, than hands filling the wish > > > lists and voting about them. > > > > Abso-freakin-lutely! :) > > > > > > > > The Pharo team did marvelous job, I assume with a lot of investment of > > > their personal time and energy. They also did quite good job at > > > setting their targets since they already managed at transforming huge > > > but sometimes hectic Squeak core into consistent development product. > > > > > > The way things currently work nicely reflect this, you can freely > > > float your ideas on the mailing list, but do not expect that someone > > > else should do it just because of that. But the better the idea is, > > > and the larger your contribution to Pharo is, chances of it being > > > implemented will rise. Otherwise, roll up your sleeves, and do it for > > > yourself. If that is too complicated, consider doing something else > > > simpler but usefull. > > > > > > > I am always discussing ideas before going to implement them. > > And for things i do, if i not sure if i doing the best way, or there > > are multiple 'nice' > > ways to solve the problem, i asking people, what they prefer. > > In that way people staying in course of what i do, and sometimes could > > give an advice or help by > > other means. > > But i don't expecting much, because we all busy with own agendas. > > > > > rush > > > http://www.cloud208.com/ > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > > > >

Dec. 11, 2010

Re: [Pharo-users] Money AND Feature requests

by Geoffroy Couprie

Hello, On Sat, Dec 11, 2010 at 10:20 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 10, 2010, at 11:00 PM, laurent laffont wrote: > >> Thinking again about this idea of voting system for features we would like to see in Pharo. >> >> I won't pay 10 euros / month for someone to develop full time on Pharo on what I do not control (may not be the best words to explain my feelings :) >> >> But I'm ready to give 30 to 50 euros to raise money to develop the most wanted feature from a voting system. This give more visibility. >> >> It's easier to make a one shot donation than give XXeuros/month. > > Good! > Tell us what architecture we can use for that. I should find some time to build a association of loi 1901 and get a paypal account for pharo. > You should take a look at Flattr for donations. Also, in case some want to donate for specific feature, there are crowdfunding solutions like kickstarter. > > >> >> So one way to achieve this is to set up a voting system AND associated raising money system to develop the most wanted feature for one month. >> >> Another way is to pick the most wanted feature for Google Summer of code. > > Don't expect anything from it > >> With enough money one can stop his work for one month and develop exclusively for Pharo. If it's too hard to raise money for one month, we can try 15 days. I've seen that some great developers can do fantastic stuff in 15 days when he loves it :) >> >> Laurent Laffont >> >> On Fri, Dec 10, 2010 at 3:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 10 December 2010 13:32, Davorin Rusevljan >> <davorin.rusevljan(a)gmail.com> wrote: >> > On Fri, Dec 10, 2010 at 1:06 PM, Alan Rodas <alanrodas(a)gmail.com> wrote: >> >> I'm relatively new to Pharo, maybe this has been tried before, but what >> >> about a forum where the ideas are published. >> >> Each idea could be a thread in the forum, and the people that would like to >> >> contribute may comment there. What it may be interesting is that the whole >> >> discussion about an idea could live in the thread, and you can keep track of >> >> old discussions and the state of a feature. >> >> If you keep your ideas for yourself, and you cannot implement something by >> >> your own, that idea will die there. If you allow people to comment on ideas, >> >> maybe two or more people have the same, and they can start working on >> >> it together. A forum allows for contacting people, and sharing, and, in that >> >> way, maybe the community will grow (Some developers feel they can do >> >> something because they don't have the time to do it by their own, or they >> >> don't have the skills, but they can help to a dev team that share the same >> >> goals.) >> >> >> >> >> >> Is just a thought. >> >> If you did it before and didn't work, my apologies. >> > >> > Well, those are all nice thoughts. I am also relatively new to Pharo >> > though, I am with Smalltalk for quite a long time. In my humble >> > opinion, while both are always nice to have, at this stage Pharo, much >> > needs more hands willing to do the work, than hands filling the wish >> > lists and voting about them. >> >> Abso-freakin-lutely! :) >> >> > >> > The Pharo team did marvelous job, I assume with a lot of investment of >> > their personal time and energy. They also did quite good job at >> > setting their targets since they already managed at transforming huge >> > but sometimes hectic Squeak core into consistent development product. >> > >> > The way things currently work nicely reflect this, you can freely >> > float your ideas on the mailing list, but do not expect that someone >> > else should do it just because of that. But the better the idea is, >> > and the larger your contribution to Pharo is, chances of it being >> > implemented will rise. Otherwise, roll up your sleeves, and do it for >> > yourself. If that is too complicated, consider doing something else >> > simpler but usefull. >> > >> >> I am always discussing ideas before going to implement them. >> And for things i do, if i not sure if i doing the best way, or there >> are multiple 'nice' >> ways to solve the problem, i asking people, what they prefer. >> In that way people staying in course of what i do, and sometimes could >> give an advice or help by >> other means. >> But i don't expecting much, because we all busy with own agendas. >> >> > rush >> > http://www.cloud208.com/ >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > >

Dec. 11, 2010

Re: [Pharo-users] Money AND Feature requests

by StÃ©phane Ducasse

On Dec 10, 2010, at 11:00 PM, laurent laffont wrote: > Thinking again about this idea of voting system for features we would like to see in Pharo. > > I won't pay 10 euros / month for someone to develop full time on Pharo on what I do not control (may not be the best words to explain my feelings :) > > But I'm ready to give 30 to 50 euros to raise money to develop the most wanted feature from a voting system. This give more visibility. > > It's easier to make a one shot donation than give XXeuros/month. Good! Tell us what architecture we can use for that. I should find some time to build a association of loi 1901 and get a paypal account for pharo. > > So one way to achieve this is to set up a voting system AND associated raising money system to develop the most wanted feature for one month. > > Another way is to pick the most wanted feature for Google Summer of code. Don't expect anything from it > With enough money one can stop his work for one month and develop exclusively for Pharo. If it's too hard to raise money for one month, we can try 15 days. I've seen that some great developers can do fantastic stuff in 15 days when he loves it :) > > Laurent Laffont > > On Fri, Dec 10, 2010 at 3:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 December 2010 13:32, Davorin Rusevljan > <davorin.rusevljan(a)gmail.com> wrote: > > On Fri, Dec 10, 2010 at 1:06 PM, Alan Rodas <alanrodas(a)gmail.com> wrote: > >> I'm relatively new to Pharo, maybe this has been tried before, but what > >> about a forum where the ideas are published. > >> Each idea could be a thread in the forum, and the people that would like to > >> contribute may comment there. What it may be interesting is that the whole > >> discussion about an idea could live in the thread, and you can keep track of > >> old discussions and the state of a feature. > >> If you keep your ideas for yourself, and you cannot implement something by > >> your own, that idea will die there. If you allow people to comment on ideas, > >> maybe two or more people have the same, and they can start working on > >> it together. A forum allows for contacting people, and sharing, and, in that > >> way, maybe the community will grow (Some developers feel they can do > >> something because they don't have the time to do it by their own, or they > >> don't have the skills, but they can help to a dev team that share the same > >> goals.) > >> > >> > >> Is just a thought. > >> If you did it before and didn't work, my apologies. > > > > Well, those are all nice thoughts. I am also relatively new to Pharo > > though, I am with Smalltalk for quite a long time. In my humble > > opinion, while both are always nice to have, at this stage Pharo, much > > needs more hands willing to do the work, than hands filling the wish > > lists and voting about them. > > Abso-freakin-lutely! :) > > > > > The Pharo team did marvelous job, I assume with a lot of investment of > > their personal time and energy. They also did quite good job at > > setting their targets since they already managed at transforming huge > > but sometimes hectic Squeak core into consistent development product. > > > > The way things currently work nicely reflect this, you can freely > > float your ideas on the mailing list, but do not expect that someone > > else should do it just because of that. But the better the idea is, > > and the larger your contribution to Pharo is, chances of it being > > implemented will rise. Otherwise, roll up your sleeves, and do it for > > yourself. If that is too complicated, consider doing something else > > simpler but usefull. > > > > I am always discussing ideas before going to implement them. > And for things i do, if i not sure if i doing the best way, or there > are multiple 'nice' > ways to solve the problem, i asking people, what they prefer. > In that way people staying in course of what i do, and sometimes could > give an advice or help by > other means. > But i don't expecting much, because we all busy with own agendas. > > > rush > > http://www.cloud208.com/ > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Dec. 11, 2010

Re: [Pharo-users] Money AND Feature requests

by laurent laffont

Thinking again about this idea of voting system for features we would like to see in Pharo. I won't pay 10 euros / month for someone to develop full time on Pharo on what I do not control (may not be the best words to explain my feelings :) But I'm ready to give 30 to 50 euros to raise money to develop the most wanted feature from a voting system. This give more visibility. It's easier to make a one shot donation than give XXeuros/month. So one way to achieve this is to set up a voting system AND associated raising money system to develop the most wanted feature for one month. Another way is to pick the most wanted feature for Google Summer of code. With enough money one can stop his work for one month and develop exclusively for Pharo. If it's too hard to raise money for one month, we can try 15 days. I've seen that some great developers can do fantastic stuff in 15 days when he loves it :) Laurent Laffont On Fri, Dec 10, 2010 at 3:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 December 2010 13:32, Davorin Rusevljan > <davorin.rusevljan(a)gmail.com> wrote: > > On Fri, Dec 10, 2010 at 1:06 PM, Alan Rodas <alanrodas(a)gmail.com> wrote: > >> I'm relatively new to Pharo, maybe this has been tried before, but what > >> about a forum where the ideas are published. > >> Each idea could be a thread in the forum, and the people that would like > to > >> contribute may comment there. What it may be interesting is that the > whole > >> discussion about an idea could live in the thread, and you can keep > track of > >> old discussions and the state of a feature. > >> If you keep your ideas for yourself, and you cannot implement something > by > >> your own, that idea will die there. If you allow people to comment on > ideas, > >> maybe two or more people have the same, and they can start working on > >> it together. A forum allows for contacting people, and sharing, and, in > that > >> way, maybe the community will grow (Some developers feel they can do > >> something because they don't have the time to do it by their own, or > they > >> don't have the skills, but they can help to a dev team that share the > same > >> goals.) > >> > >> > >> Is just a thought. > >> If you did it before and didn't work, my apologies. > > > > Well, those are all nice thoughts. I am also relatively new to Pharo > > though, I am with Smalltalk for quite a long time. In my humble > > opinion, while both are always nice to have, at this stage Pharo, much > > needs more hands willing to do the work, than hands filling the wish > > lists and voting about them. > > Abso-freakin-lutely! :) > > > > > The Pharo team did marvelous job, I assume with a lot of investment of > > their personal time and energy. They also did quite good job at > > setting their targets since they already managed at transforming huge > > but sometimes hectic Squeak core into consistent development product. > > > > The way things currently work nicely reflect this, you can freely > > float your ideas on the mailing list, but do not expect that someone > > else should do it just because of that. But the better the idea is, > > and the larger your contribution to Pharo is, chances of it being > > implemented will rise. Otherwise, roll up your sleeves, and do it for > > yourself. If that is too complicated, consider doing something else > > simpler but usefull. > > > > I am always discussing ideas before going to implement them. > And for things i do, if i not sure if i doing the best way, or there > are multiple 'nice' > ways to solve the problem, i asking people, what they prefer. > In that way people staying in course of what i do, and sometimes could > give an advice or help by > other means. > But i don't expecting much, because we all busy with own agendas. > > > rush > > http://www.cloud208.com/ > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Dec. 10, 2010

Re: [Pharo-users] Feature requests

by Igor Stasenko

On 10 December 2010 13:32, Davorin Rusevljan <davorin.rusevljan(a)gmail.com> wrote: > On Fri, Dec 10, 2010 at 1:06 PM, Alan Rodas <alanrodas(a)gmail.com> wrote: >> I'm relatively new to Pharo, maybe this has been tried before, but what >> about a forum where the ideas are published. >> Each idea could be a thread in the forum, and the people that would like to >> contribute may comment there. What it may beÂ interestingÂ is that the whole >> discussion about an idea could live in the thread, and you can keep track of >> old discussions and the state of a feature. >> If you keep your ideas for yourself, and you cannot implement something by >> your own, that idea will die there. If you allow people to comment on ideas, >> maybe two or more people have the same, and they can start working on >> itÂ together. A forum allows forÂ contactingÂ people, and sharing, and, in that >> way, maybe the community will grow (SomeÂ developers feel they can do >> somethingÂ becauseÂ they don't have the time to do it by their own, or they >> don't have the skills, but they can help to a dev team that share the same >> goals.) >> >> >> Is just a thought. >> If you did it before and didn't work, my apologies. > > Well, those are all nice thoughts. I am also relatively new to Pharo > though, I am with Smalltalk for quite a long time. In my humble > opinion, while both are always nice to have, at this stage Pharo, much > needs more hands willing to do the work, than hands filling the wish > lists and voting about them. Abso-freakin-lutely! :) > > The Pharo team did marvelous job, I assume with a lot of investment of > their personal time and energy. They also did quite good job at > setting their targets since they already managed at transforming huge > but sometimes hectic Squeak core into consistent development product. > > The way things currently work nicely reflect this, you can freely > float your ideas on the mailing list, but do not expect that someone > else should do it just because of that. But the better the idea is, > and the larger your contribution to Pharo is, chances of it being > implemented will rise. Otherwise, roll up your sleeves, and do it for > yourself. If that is too complicated, consider doing something else > simpler but usefull. > I am always discussing ideas before going to implement them. And for things i do, if i not sure if i doing the best way, or there are multiple 'nice' ways to solve the problem, i asking people, what they prefer. In that way people staying in course of what i do, and sometimes could give an advice or help by other means. But i don't expecting much, because we all busy with own agendas. > rush > http://www.cloud208.com/ -- Best regards, Igor Stasenko AKA sig.

Dec. 10, 2010

Re: [Pharo-users] Feature requests

by Davorin Rusevljan

On Fri, Dec 10, 2010 at 1:06 PM, Alan Rodas <alanrodas(a)gmail.com> wrote: > I'm relatively new to Pharo, maybe this has been tried before, but what > about a forum where the ideas are published. > Each idea could be a thread in the forum, and the people that would like to > contribute may comment there. What it may beÂ interestingÂ is that the whole > discussion about an idea could live in the thread, and you can keep track of > old discussions and the state of a feature. > If you keep your ideas for yourself, and you cannot implement something by > your own, that idea will die there. If you allow people to comment on ideas, > maybe two or more people have the same, and they can start working on > itÂ together. A forum allows forÂ contactingÂ people, and sharing, and, in that > way, maybe the community will grow (SomeÂ developers feel they can do > somethingÂ becauseÂ they don't have the time to do it by their own, or they > don't have the skills, but they can help to a dev team that share the same > goals.) > > > Is just a thought. > If you did it before and didn't work, my apologies. Well, those are all nice thoughts. I am also relatively new to Pharo though, I am with Smalltalk for quite a long time. In my humble opinion, while both are always nice to have, at this stage Pharo, much needs more hands willing to do the work, than hands filling the wish lists and voting about them. The Pharo team did marvelous job, I assume with a lot of investment of their personal time and energy. They also did quite good job at setting their targets since they already managed at transforming huge but sometimes hectic Squeak core into consistent development product. The way things currently work nicely reflect this, you can freely float your ideas on the mailing list, but do not expect that someone else should do it just because of that. But the better the idea is, and the larger your contribution to Pharo is, chances of it being implemented will rise. Otherwise, roll up your sleeves, and do it for yourself. If that is too complicated, consider doing something else simpler but usefull. rush http://www.cloud208.com/

Dec. 10, 2010

Re: [Pharo-users] Feature requests

by Stanislav Paskalev

There is such a forum and it's mirrored / synced to these mailing lists. See http://forum.world.st/ Stanislav Paskalev On Fri, Dec 10, 2010 at 2:06 PM, Alan Rodas <alanrodas(a)gmail.com> wrote: > I'm relatively new to Pharo, maybe this has been tried before, but what > about a forum where the ideas are published. > Each idea could be a thread in the forum, and the people that would like to > contribute may comment there. What it may beÂ interestingÂ is that the whole > discussion about an idea could live in the thread, and you can keep track of > old discussions and the state of a feature. > If you keep your ideas for yourself, and you cannot implement something by > your own, that idea will die there. If you allow people to comment on ideas, > maybe two or more people have the same, and they can start working on > itÂ together. A forum allows forÂ contactingÂ people, and sharing, and, in that > way, maybe the community will grow (SomeÂ developers feel they can do > somethingÂ becauseÂ they don't have the time to do it by their own, or they > don't have the skills, but they can help to a dev team that share the same > goals.) > > > Is just a thought. > If you did it before and didn't work, my apologies. > > > Cheers > -- > Alan Rodas Bonjour

Dec. 10, 2010

Re: [Pharo-users] Feature requests

by Alan Rodas

I'm relatively new to Pharo, maybe this has been tried before, but what about a forum where the ideas are published. Each idea could be a thread in the forum, and the people that would like to contribute may comment there. What it may be interesting is that the whole discussion about an idea could live in the thread, and you can keep track of old discussions and the state of a feature. If you keep your ideas for yourself, and you cannot implement something by your own, that idea will die there. If you allow people to comment on ideas, maybe two or more people have the same, and they can start working on it together. A forum allows for contacting people, and sharing, and, in that way, maybe the community will grow (Some developers feel they can do something because they don't have the time to do it by their own, or they don't have the skills, but they can help to a dev team that share the same goals.) Is just a thought. If you did it before and didn't work, my apologies. Cheers -- Alan Rodas Bonjour

Dec. 10, 2010

Re: [Pharo-users] Feature requests

by Marcin Tustin

It might be nice to keep track of who says they are interested in having a feature, so whoever wants to take the lead on implementation knows who to ask to pitch in. On Fri, Dec 10, 2010 at 8:52 AM, Geert Claes <geert.wl.claes(a)gmail.com>wrote: > > > James Ashley wrote: > > > > ... > > 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... > > > > 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. > > > > This is not a fight, it's just a very passionate discussion ... mind you, > English is not the first language for a lot people here and even though > things may get slightly misconstrued and discussions do sometimes appear to > be intense, I bet they'll still gladly have a beer together :) > > To summarize: > - The current list of "ideas to implement" lives here: > http://code.google.com/p/pharo/wiki/IdeasToImplement > - Does the list of ideas have a voting system? No. Why? There is no way > to ensure ideas will be implemented according to the votes. > - How do we know which ideas are popular? Ideas are discussed on the > mailing list. > - Can anyone suggest new ideas? Abso-freakin-lutely! > > So I guess the only thing that may need to be elaborated a bit further is > how an idea that has been discussed on the mailing list (e.g. native > windows) will make its way to the list of "ideas to implement" and everyone > can happily look forward to start the weekend with a beer in hand and smile > on their face :) > -- > View this message in context: > http://forum.world.st/Feature-requests-tp3077333p3081581.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- Marcin Tustin Mobile: 07773787105

Dec. 10, 2010

Re: [Pharo-users] Feature requests

by Geert Claes

James Ashley wrote: > > ... > 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... > > 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. > This is not a fight, it's just a very passionate discussion ... mind you, English is not the first language for a lot people here and even though things may get slightly misconstrued and discussions do sometimes appear to be intense, I bet they'll still gladly have a beer together :) To summarize: - The current list of "ideas to implement" lives here: http://code.google.com/p/pharo/wiki/IdeasToImplement - Does the list of ideas have a voting system? No. Why? There is no way to ensure ideas will be implemented according to the votes. - How do we know which ideas are popular? Ideas are discussed on the mailing list. - Can anyone suggest new ideas? Abso-freakin-lutely! So I guess the only thing that may need to be elaborated a bit further is how an idea that has been discussed on the mailing list (e.g. native windows) will make its way to the list of "ideas to implement" and everyone can happily look forward to start the weekend with a beer in hand and smile on their face :) -- View this message in context: http://forum.world.st/Feature-requests-tp3077333p3081581.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 10, 2010

Re: [Pharo-users] Feature requests

by StÃ©phane Ducasse

andres what can I say? Write PEPs take a couple of them that you think are really important, write them get people involved and we see in 6 or 12 months from now. If it succeeds I will be more than happy. Believe me. > 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. yes this is about building synergy about an idea. (you see I'm not mean I could have say around an idea that nobody has the financial impact to get real) > 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'm positive: I show you all the features we dream about. Take 3 and build a PEP and succeed building them and we will all be happy. > 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. >

Dec. 10, 2010

Re: [Pharo-users] Feature requests

by James Ashley

On Thu, Dec 9, 2010 at 7:38 PM, andres <andres(a)lifia.info.unlp.edu.ar> 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

Dec. 10, 2010

Re: [Pharo-users] Feature requests

by andres

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

Dec. 10, 2010

Re: [Pharo-users] Feature requests

by Stefan Marr

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

Dec. 9, 2010

Re: [Pharo-users] Feature requests

by Igor Stasenko

10 man-years :) On 9 December 2010 22:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 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.

Dec. 9, 2010

Re: [Pharo-users] Feature requests

by StÃ©phane Ducasse

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.

Dec. 9, 2010

Re: [Pharo-users] Feature requests

by StÃ©phane Ducasse

> 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 <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 Mariano Martinez Peck

On Wed, Dec 8, 2010 at 9:46 PM, George Herolyants < george.herolyants(a)gmail.com> wrote: > 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? +1 I think a wishlist is worth it even if there won't be manpower at that moment.

Dec. 9, 2010

Re: [Pharo-users] Feature requests

by andres

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

Dec. 9, 2010

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