[Opensim-users] they way the project works and to support

[Ralf Haifisch]

Hi Crista,

thx for your comment...

> People who use opensim must have two important things in mind: (1) 
> OpenSim is not Second Life; and (2) The developers are not Linden Lab. 
> These two things are subtle but critical. 

--> never thought something else...

Specifically, to put it 
> bluntly, "costumer service" is non-existent. 

--> i guess thats, not true any more.
Based on the feeling of users, opensim is afunctional software. People use
it.
Osgrid is the open developers and testing grid - but got a living place as
well.

So, as you aren´t payed for your work - there are volunteers doing the
cumstomer service, as well.
Pretty much people I learned to know who are willing to introduce newbies,
to collect information from them and forward to operatos and developers.
Yes, it´s no service level based payed customer service (do lindens have a
service level ??) - but there is one, even in osgrid.  ;-)

Ppl who run OpenSim grids 
> in an organized manner may have their costumer service for their grids, 
> but there is no such thing for the OpenSim project itself. The 
> developers are [almost] all volunteers who contribute their time for a 
> variety of different personal reasons.

> There is no JIRA here, nor is there the concept of "voting for features" 
> outside core developers, because the core developers always work on 
> whatever parts they are more interested in working, and not on some list 
> of features that is produced and prioritized externally.

--> got that.  I still would think, the goal would be a functional 3D system
- it´s far away from a case study or technical evalution.  But I understand,
that devs are not interested to pay their time on things they are not
interested. I will opt out from supporting, if people just try to make me
copy each line from a manual to forum, too.

> If someone wants something new implemented, the process is always the
same:

> (a) define what you want and discuss it on the -dev mailing list
> (b) if you're a programmer, code it yourself and submit a patch via mantis
> (c) if you're not a programmer, convince someone who is to implement it 
> for you and submit a patch via mantis
> (d) all patches on mantis are evaluated by the core developers and 
> committed if there are no objections


--> got that.  Up to yesterday I thought any, that the devs mailing list is
for dev´s.
However - it´s not only me, who is flooded by the number of communication
channels.  
To me it seems, that is customer support role means as well, that we try to
leanr about all the tools and put the customers (user, use cases) topics in
the right pipeline.

> If someone notices an annoying bug that is getting in their way, the 
> process is also always the same:

> (a) define what the bug is in Mantis
> (b) if you're a programmer and you enjoy doing these things, try to fix 
> it yourself and submit a patch
> (c) if you're not a programmer, and you want the bug fixed, you need to 
> describe the problem with as much detail as possible or the developers 
> won't be able to even reproduce it. Without reproduction, there is no 
> possible fix.

--> I would not go with (c) , but a good description is needed for sure. 
   I still do architure and code reviews in RL project some times (i.e.
security), so there is another way.  *gg*


The open questions would be:

Shouldn´t be there a extra tool for feature description and voting ?
Much easier to develop the idea and see if there´s realy demand.
After all there will still be the search for a dev.

Shouldn´t be the "feature" tag be removed in mantis ?
It was at least misleading to me.  And - believe me - I did read quite a lot
over month.
But I hardly find the pages I already did had read.  So stuff like your
steps above are at least not easy to find.
Maybe just avoid the "feature" to not get people dropping in feature
requests..


Cheers
Ralf