[opensource-dev] Proposal: Howto add a new feature to snowglobe.

[Tigro Spottystripes]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

what if the bug fix includes changes in behavior that for some users is
considered a bug in itself? (like how it happened at first with the
issue of auto-granted permissions permanency being abused, where the
initial proposal of simply auto-revoking hen the avatar stands up would
break content that produced a graceful transition from sitting to
standing up by animating the avatar right after it stopped being sat on
the prim)

On 18/3/2010 09:02, Carlo Wood wrote:
> 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.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuilDcACgkQ8ZFfSrFHsmUIlgCeIc3qJYNgi6bqHZ0IDJyxTXRK
rE8An1aHFSXMpCZDLB0msMUoRTosBy3M
=8Xas
-----END PGP SIGNATURE-----