Aloha, Some time ago we talked about the automation of (developmentish) tasks, back then I suggested that the first step to doing that right would be to find out where time is spent to being with.
Now to find out where time is spent we first need some semi-solid data, of course when talking about time a developer spends on something it is near impossible to put a price tag on it as one person might need 5 minutes to create a new package whereas another may need 10 (being more precise to create long-term value and whatnot). So there are two questions I have for you: a) Would anyone be willing to do time tracking (i.e. use ktimetracker or something to actually collect data on time spent-per-task)? b) What tasks do you do (i.e. simply a list of things you tend to do in say one month)? Given that a sufficient amount of you would be willing to track task time for a month on a superset of all tasks (that I hope to get through b)) we should be able to get a clear idea where most of our time is *actually* spent and find ways to make it the applied processes more efficient. For all I care you can also start throwing random numbers at me, but in my experience perceived time spent is often enough faaaaar from reality (what with getting caught up in something interesting etc.) .... random background info since I am in a rambling mood today, not particularly useful to anyone, so ignore if you want :P time spent by person foo != time spent by person bar, that's why we need a sufficient sample size. time spent != time wasted, once we have data we can assign specific tasks a degree of wastefulness, the higher the wastefulness the more likely we should so something about it. generally speaking the more time you have to spend yourself doing things the higher the wastefulness. how wastes time you ask? your computer ;) (or vice versa ;)) for example test building, while consuming lots and lots of time it actually wastes very little because you can actively do other stuff meanwhile, perhaps you would be doing bug triage or ISO testing or simply watch futurama for recreational purposes. bug triage OTOH has 100% wastefulness unless you actually pair it with say test building. ISO testing probably also has 100% wastefulness, which essentially means that you cannot do bug triage and ISO testing at the same time (that is you can, but if you think about it, to look at bugs while doing testing you need to interrupt the testing...). suffice to say that is bad. to give an example of how this would work in the end (using random values of course): test building spent: 110h/person/month waste: 20% (build fixes, symbol updates, log review...) = 22h/person/month remedy: semi-automatic log review & semi-automatic symbol updates, cost: 10h implementation, safes 5% waste, final waste 15% = 16.5h/person/month iso testing spent: 22h/person/moth waste: 100% = 22h/person/month remedy: ldtp testing support in ubiquity & tests, cost: 110h implementation, safes 50% waste, final waste 50% = 11h/person/month so doing relatively small adjustments to build automation (which is already largely automated) would in this example be more efficient than automating iso testing from scratch, iff people would however like to pair ISO testing with bug triage (which would be best as I would of course like a QA team to handle all that stuff...) then you would want to go for the expensive ISO testing improvement and through reducing waste there free up time to spend on any other task, such as bug triage. HS -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
