[opensource-dev] Open Development project: extendingavatarwearables

Nyx Linden nyx at lindenlab.com
Sat Mar 27 22:13:36 PDT 2010


Carlo,
    I've been given the resources (my time, QA, release, and external
development) to do this project in one project cycle, not two. It is yet to
be seen, but it would not be surprising if my time and attention is needed
elsewhere next project cycle, as our list of tasks to do far outweighs our
resources with which to implement them. As such, we need to weigh the
cost/benefit of each feature carefully.

   For this project, we need to ship the ability to wear multiple wearables
of the same type, a new outfit editor, and a new wearable editor (to replace
the appearance editor). That is the minimum work that must be done during
this project cycle, and what we have resources allocated to accomplish. I'm
certainly willing to consider and discuss other potential features or
designs!
Keep in mind, though, that I am just one developer, working on limited
resources (time, other devs, QA, release, etc). I'm already planning on
working on several features above and beyond the minimum, but this work
needs to be considered carefully.

This is still a Linden-developed featureset, so we have some pretty specific
requirements as far as scheduling is concerned. I'm planning on gathering
community feedback throughout the process, but without more developers on
the project I need to be careful what I commit to. External developers are
welcome to join on the project and accelerate development to allow a broader
featureset to be implemented, but for the time being I am only one tiny
robot swimming in a sea of feature requests!

 -Nyx


On Fri, Mar 26, 2010 at 5:18 PM, Carlo Wood <carlo at alinoe.com> wrote:

> Jonathan,
>
> I have no disrespect at all for Nyx. And yes, it's highly appreciated
> that he asks us for input instead of just implementing it.
>
> Still, if nothing in his original design is going to be changed
> then the effect is almost the same; except if this list is
> convinced that his original design is indeed the best.
>
> Apparently that stands or falls with having time (money) to do
> anything beyond what he already planned to do, and therefore
> explaining that is the only way to make the list understand this.
>
> Hence my question. Not because I think he is wrong, but because
> I want to know (and understand): Why not implement the extra
> requests from this list and then release the whole feature
> three months later? Imho it IS better to delay the feature and
> release a really well-thought-out new feature that will really
> work for a long time, than to be 3 months sooner and have people
> feel frustrated about little shortcomings for the next 3 years.
>
> Specifically to Jonathan: I'm sure this is a misunderstanding
> in the way my post came across. I appologise for that. It's
> sometimes hard to come accross correctly in written emails
> (I'm not even good at it in RL).
>
> On Fri, Mar 26, 2010 at 02:52:39PM -0500, Jonathan Irvin wrote:
> >
> > On Fri, Mar 26, 2010 at 06:56, Carlo Wood <carlo at alinoe.com> wrote:
> >
> >     It bothers me a bit that we (you) would choose to go
> >     for an implementation that is not the best or the
> >     ideal one, ONLY because you want to push out a new
> >     feature "in time".
> >
> >
> > Carlo, it pains me to see you have this attitude towards the
> > Lindens...especially those who are in here trying to communicate with
> us.
> > ***Linden Labs has limited resources*** They can't just magically
> allocate time
> > and money to a feature that would be awesome because you think so.  They
> have
> > time and money constraints.
> >
> >
> >     Personally, I'd first design how I'd want it to look
> >     from the user point of view (what most of the discussion
> >     from the community is about) without taking into account
> >     coding arguments. And once we have that, I'd just
> >     implement it, no matter the costs or time needed.
> >     That is what coders do: they implement what is requested.
> >
> >
> > This is a blind perspective to have.  Coding constraints come into play
> because
> > coding takes time and when you are on a payroll with a budget, time =
> money.
> > You have to sacrifice the really awesome feature that will take a while
> for the
> > ones that are easy, but have an ok benefit.
> >
> > The Lindens aren't tools, my friend.  Perhaps showing more respect for
> them
> > will give you respect in return by getting us new features.  And, keep in
> mind,
> > this is an OpenSource forum.  If you have an idea, make it happen and
> pitch it
> > to us.  Code it yourself and post it to the open forum.  The lindens have
> > enough on their plate as it is which is why they went the opensource
> route to
> > begin with...having the assistance of the community make a better
> product.
> >
> >
> >     Thus, since for almost everything we said so far your
> >     argument is: we can't do that within the given timeframe;
> >     can you defend, or at least make acceptable and understandable
> >     that "a" new feature has to be added in 3 months, even if
> >     that new feauture is a bit inferior compared to what
> >     that UI could have looked like?
> >
> >
> > Again, show some respect here.  The lindens have a lot on their plate and
> are
> > wanting you to make a business case for this.  They need to know a
> feasible,
> > tangible way they can impliment feature ABC while not over taxing their
> > resources.  Also, this feature needs to be used by the whole and not a
> small
> > percentage of users.
> >
> >
> >     Changing it AGAIN in the near future (ie, 6 months later)
> >     is probably not going to happen for several reasons :/
> >     So, not doing it right now has almost the same implications
> >     as deciding to never do it. I'd really like to understand
> >     why that is the best thing to do.
> >
> >     Thanks for discussing this with us,
> >     Carlo Wood <carlo at alinoe.com>
> >
> >     PS With regards to the UI design.
> >       I like the concept of "click wear" inserts the wearable
> >       in a default place, after which you can reorder it.
> >       And where this inserting means "at the top of a folder
> >       that one of the currently existing wearable categories".
> >       It just makes sense.
> >
> >       But, in the end the goal should be that wearer can
> >       determine the order of every texture layer, or at
> >       least to a great extend, including:
> >       - Tucking in jackets or not (jacket <-> pants ordering)
> >         (my proposal was to add a pseudo jacket, below or
> >         above which other jackets are below or above the pants).
> >       - Wearing shirts over jackets (jacket <-> shirt ordering)
> >         (proposal was to be able to dump a jacket in the 'shirt'
> >         folder if one wishes).
> >
> >     _______________________________________________
> >     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
> >
> >
> > In conclusion, have a little more common courtesy.  The fact that the
> Lindens
> > are participating as often as they are and engaging in good conversation
> should
> > be something you shouldn't take for granted.
> >
> >
> > Think good business.
> >
>
> --
> Carlo Wood <carlo at alinoe.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100328/b4d0ab0f/attachment-0001.htm 


More information about the opensource-dev mailing list