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 <andres@lifia.info.unlp.edu.ar>:
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.