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):
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% =
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
kubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel