[sldev] Philip's viewer; was: Tuesday Hippotropolis Meeting w/voice

Glen gcanaday at gmail.com
Thu Apr 9 16:00:00 PDT 2009


I thought I'd start. I wrote a 3-paragraph novel-in-a-nutshell response. 
Decided that was a bad idea since it was all whining anyway. Deleted it.

If next week goes the same as this week, I'll delete my response again.

lol ;P At work we call these "battle plans" and the work finished 
"stats" since they can be graphed. Management is funny that way. Weekly 
progress reports and personal targets are an excellent idea. They keep 
others informed of what's going on... sorta like turn signals on the car.

--GC

Philip Rosedale wrote:
> Adding some thoughts... Robin and Merov have made some good responses 
> too...
> 
> I am a huge believer in transparency and freedom:  Inotherwards, if you 
> are fearless about telling people early and often what you are doing, 
> you are probably doing the right things without needing to be told.  At 
> Linden most folks (about 85%+) publish weekly emails to the entire 
> company listing what their objectives are for the week, and how they did 
> last week.  Perhaps we could do that here too!!  It might be interesting.
> 
> So in that spirit, I'd say that sending mail to SL-dev saying "I am 
> about to start working on X, what do folks think?" seems like a great 
> idea.  Design review suggests an approval process barring further work, 
> which I don't think would be appropriate.   But talk on this list about 
> what you think would make sense to put into this viewer before starting 
> coding work - Yes!
> 
> Also I agree with what merov said about committers, it seems like 
> building a growing list of committers who distribute the load of giving 
> feedback on what should/shouldn't go in is the right strategy.
> 
> P
> 
> Mike Monkowski wrote:
>> Very good meeting, but I still have questions about the process.
>>
>> One thing that was brought up was that code review is a good thing.  
>> So make the code review the gatekeeper.  Nothing gets into Philip's 
>> branch unless it goes through a code review, which could be a 
>> regularly scheduled meeting on Hippotropolis (or elsewhere) or it 
>> could be called by Philip whenever he feels like it.  Anyone could 
>> comment on the code, but Philip would be the ultimate "go" or "no go" 
>> authority.
>>
>> Is documentation (on the wiki?) required for a "go"?
>>
>> Before I spend my time coding, I might want to know whether it has a 
>> chance of making it into Philip's viewer.  Do we need a design review 
>> as well?
>>
>> That gets stuff in, but how does it get back out to trunk?  How often? 
>> Who does it?
>>
>> And how do other changes to trunk (or RC?) get into Philip's branch? 
>> Who keeps the two in sync?  What happens when LL code changes break 
>> the new features?  What about when my feature breaks your feature?  
>> Who is responsible for fixing them?  If I fix something that came from 
>> trunk or RC, how does it get fixed back there?
>>
>> If someone abandons his code, how does it get removed?
>>
>> I'll probably think of more questions, but this will do for now.
>>
>> Mike
>> Mm Alder
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
> 


More information about the SLDev mailing list