[Owncloud] Releases and stuff

[Christian Reiner]

Hello all, 
I'd like to add two cents to the valuable points Thomas & Thomas made: 

On Wednesday 18 July 2012 02:00:27 Thomas Tanghus wrote:
> [...] release [...] how this is to be handled [...]
> [...] the 4.0 release gave us some bad cred [...]
> [...] really have an overview of what's supposed to be in that release [...]

On Wednesday 18 July 2012 02:00:27 Thomas Müller wrote:
> [...] some kind of wiki/doc/blog [...]
> [...] I would have liked to see some concept paper on that in advance [...]

Also others have mentioned ideas going into the same directions. 

I partly followed the discussion about test principles and coder 
responsibilities and all here on the mailing list. Many valuable things have 
been said. However there is one thing that no one appears to think about, 
which looks a little odd to me: 

Those approaches to testing and quality enhancements I noticed all targeted at 
the existing team. That means either doubled work load (which won't fly) or 
slowed down progress (which is not wanted and fortunately not the case) or 
gaps in exactly those points all here regard as so important and required 
(which is a desaster). 

In my former position (I quit about a good year ago) I learned a few lessons 
if it comes to releases: 
- trusting in developers to reliable test their own code makes no sense
( no offense meant, I am a developer myself )
- happily contributing until the day before release can't work out
( certainly all fixes with good intentions, but we all know how that is...)
- direct and agile communication in favor over formal rules is silly
( formal rules and communication are completely separate )
I learned that even in my former team of only 6 developers a formal schedule 
with things like feature freezes, milestone planning and a formal and 
documented test catalog may look bloated at first. However it clearly improves 
quality _if_ actually followed. And this is the crucial point. 
It was a hard lesson for me to learn, but at one point (one very important 
project) I brought myself to hire someone external to do the dirty work: the 
formal tracking, checking for test progress, deciding about last-minute-
things, ... And the step turned out as one of the best I ever made. 

Form a small test team apart from the developers, have one single external 
person control and document the progress, including tests, implementations, 
tracking, schedule and milstone planning. And hand over formal decisions to 
that external person. This way things get more formal and may slow down a 
little. But you gain transparency, a better feeling in your stomach around 
those release dates and, last not least, quality. 

Christian Reiner

-- 
arkascha
[ foss at christian-reiner.info ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20120718/2316fa59/attachment.html>