Here is some food for thought: -- Question: Who determines what is added to the viewer and what not?
I propose (to be decided by Lindens, not others) the following: There are two different categories of things that can be added to the viewer: Category 1: Bug fixes; intended behavior is not as expected. Category 2: Features; intended behavior is changed (added). Category 1 ---------- These are handled the same as category 2, but without the need to decide at the user-experience level if the patch is wanted. Thus, for *accepted* feature AND bug fix: A committer writes the patch. The patch is reviewed by other committers. No committer can stop a patch entirely, but they can request patches to be taken back to the drawing board based on: * CPU usage (FPS drop) * Memory usage * Coding style * Maintainability (how easy it is to make changes without breaking it) * Robustness (chance it breaks accidently by changes elsewhere) Committer are expected to work together and respect eachother, but especially the original committer needs to be prepared to spend another week or two to address each and every comment made by other committers (for which the jira is used). When all other committers involved, with a minimum of one other committer, are satisfied; the patch may be committed. Category 2 ---------- In the case of a new feature, the new feature should really first be discussed on this list, before being implemented. What is being discussed are the effects on the users, not the technical effects like CPU usage etc. Non-committers can (politely) provide insight and feedback, but do not have any vote on whether or not a new feature will be added. In fact, nobody has a vote: in the end it's the call of Linden Lab, where we assume that if any Linden speaks his/her decision on the list that that is the internal decision of Linden Lab (and another Linden will not suddenly oppose). Each feature must be carried by a committer. That is, someone must step forward and offer to write it, test it and be prepared to through the hassle of Catergory 1 above. In most cases this will be a committer whose own idea the feauture is, that is the advantage of putting time into actually writing (good) patches. It is not a bad thing that committers have this priveledge. Of course, it is also possible that a committer decides to backup an idea of someone else. [There is no reason he cannot be paid for that, but I expect that in general this will not be the case]. Linden Lab will take the following into account when making their decision about a new feature: * This is about Snowglobe ONLY; whether or not it's also added to the official viewer is a separate issue. * They will NOT take maintainability into account, that is the responsibility of the open source community. * If the new feature has no last impact on the user base, which can always be achieved by making it optional and/or not the default, they will let themselves strongly be influenced by the consensus of the list discussion. * The opinion of committers is taking more into account than the opinion of non-committers, because it's the committers who have to maintain the code. * The decision is made in a timely manner (ie, within two weeks after the discussion on this list dies out). If no decision is communicated within a reasonable time, they right to a final decision forfeits and the feature may be added (all with gentlemen agreement of course). For example, the Life Cycle of a new feature might be the following: * User thinks of new feature and adds it to the jira. * Several people find it and vote for it. * Feature comes to the attention of someone on this list and brings it under the attention of a committer. * Committer commits himself (haha) and post to the list with implementation detail ideas. * Everyone has their say in a civil and polite way. * The design (on "paper") goes through a few cycles until the committer that committed himself doesn't want to make more changes. * Linden Lab gives the red or green light. * In case of a green light, the committer writes a patch and tests it. Then attaches it to the jira. * At least one other committer tests it and makes comments about implementation details. * Original committer rewrites the patch and/or fixes bugs, until all other committers that want to spend time on reviewing are satidfied. * The patch is committed. -- Carlo Wood <ca...@alinoe.com> _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
