Kubuntu 17.04 Planning Meeting

[Xen]

The feeling is that when you perform tasks that in the end belong to 
some other person or group you are always out of energy performing those 
tasks.

Which is to me the biggest reason many open source projects seem to be 
struggling to get enough man power, because they are asking people to 
take on someone else's duties and are also doing that themselves. The 
consequence is that you have to "push" yourself to perform well when 
otherwise it would have come natural? Part of that is also having to 
comply with regulations and command structures. Including perhaps even 
codes of conduct and all of that. It reminds one of the 
"micro-management" issues one has in computer games. Some computer games 
are designed to provide a battle between the micro-management and 
macro-management of a certain level or field. If you do the macro well, 
the micro doesn't take any time at all. If you f*ck up the macro, the 
micro starts to take all your time and you are always running behind 
schedule, often slowing down the speed of the game in order to cope with 
it ;-).

It is particularly the distributions that seem to always having a 
problem with getting enough manpower. Maybe they are asking too much of 
themselves. A project in isolation is easily achieved, a hundred 
projects together is not. Just some thoughts. ;-). If you have 100 units 
of energy and you do 10 projects and each of them takes 11 units you are 
always short. If you do 9 projects you suddenly have 1 unit left. If you 
do 8 you suddenly have scores of energy available you can use to fill 
any gaps that fall. It is not handy to plan for exact completion given 
the resources you have. Any "room" in your planning quickly turns into 
an asset you can utilize for other things. This way you are always ahead 
of things which, rumour has it, feels really good ;-). I never worked at 
Sun, but they said, that those who worked there could clock in any time 
they wanted and choose their own hours, as long as they got the work 
done. That seems like a nice way to work. I also remember checking in 
with my boss at 10 pm to use their computers a bit. Was not a problem. 
You need breathing space.

Particularly you need to focus on what things are important and then 
identify the things you will be tempted to fall into that you don't want 
to do too much of. As long as you can get an overview on what things are 
essential and what not, and be aware of this scope at al times (but not 
at all times ;-)) things will turn out well, I think. If releases are 
only milestones you have to deal with, you can include the milestones 
within your planning, not your planning within the milestones. Then you 
would have a bit more of an "eternal" vision as to what you are doing. 
Your goals don't change from release to release, I think. Identify 5 or 
6 main objects and targets you need to be done well. Then specify those 
targets publicly or at least for yourself. And then be able to look back 
at those targets and see how well they are doing. You can then focus 
entirely on those targets and nothing else. But it also becomes clear 
what is important to you and what not, and this kind of planning can 
make it easier to stay focussed on the goals that actually matter, and 
the main value of planning is to not be distracted by paths that are not 
as fruitful as your main paths, and to not be drawn into fruitless 
exercises that don't reward anything: to know in advance what you are 
going to do and what would be smart in doing that.

For Kubuntu I think that means identifying 5 or 6 main goals and targets 
(objects to keep in order or to achieve the proper status of) and 
keeping those in your awareness and for yourself visible publicly (for 
yourself) perhaps in a wiki style or html page where you can remind 
yourself and provide a summary of its status.

Perhaps you already have that.

Such objects could of course include: driver manager, wiki 
(documentation), a statistic denoting the quality of the 
kubuntu-specific packages and their bug reports (so for instance you 
could identify a statistic denoting the level of calm or chaos 
surrounding those packages or user experiences) (the way a surgeon would 
summarize a wound or infection by the level of "calm" it has) (you can 
call that non-inflammation) and you can try to breathe calm into that 
statistic, community health (one could at least try to be aware of 
"customer" happiness, amount of people coming in, amount of people going 
out, popularity with respect to other distributions (Ubuntu proper, 
Mint), size of your team, and all of that), level of completion of your 
ulterior goals (for instance specific to a release milestone or release) 
and finally I don't know.

1) kubuntu specific tools
2) documentation
3) level of health of packages and their bug reports and experiences
4) level of health of the community
5) level of completion of goals

Who knows it could work. Maybe you shouldn't I don't know.

Regards.



Aaron Honeycutt schreef op 10-10-2016 4:39:

> For 17.04 I'd like to get the Driver Manager fixed and pushed into
> SRU's for 16.10 and 16.04 (most importantly) @All. As well as push the
> .1 release to the docs onto the doc website @Philip.

> On Tue, Oct 4, 2016 at 9:39 PM, Xen <list at xenhideout.nl> wrote:

>> Simon Quigley schreef op 05-10-2016 3:15:
>> Hello Clive,
>> 
>> On 10/03/2016 06:26 AM, Clive Johnston wrote:
>> In my honest opinion you are "jumping the gun" on this.  ZZ isn't
>> even a thing
>> until Mr Shuttleworth chooses a name and the archive is opened for
>> it.
>> 
>> Ok, I guess we are coming at it from different angles here. I want
>> to
>> start planning for Z as soon as we have the ability to start working
>> on
>> it. I would much rather get a bunch of planning done at the
>> beginning of
>> the cycle to ensure we all know what goals we have for this cycle
>> and
>> any updated procedures we might have.
>> 
>> So from now until the 13th of October, lets concentrate on getting
>> Yakkety Yak
>> out the door, by testing and getting issues fixed.  Even when YY
>> ships, bugs
>> will roll in, so we need to be actively working on this.  We have
>> lots of time
>> to plan for +1 when things settle down after YY release.
>> 
>> This is why I planned the meeting to be that Friday or that weekend.
>> I
>> honestly agree with you on that. Let's get Yakkety out the door. But
>> once Z is open, I'd like to make sure we can get a grip on it early.
>> 
>> You see where I'm coming from here, Clive?
> 
>  Just an unimportant opinion here but I observed the same sentiment
> when 15.04 was released and back then someone told me that someone for
> a paid job like mr. Riddell was could hardly be expected to "sit on
> his laurels" not doing work.
> 
> If you are doing too many things you cannot do any of them really
> right.
> 
> I feel you are working too hard. Doing too many things but then not
> having enough time for the individual things you have done.
> 
> The feeling is that all of these releasese are unfinished and as a
> consequence there are too many of them. So back when 15.04 was
> released and /instantly/ people focussed their /entire attention/ on
> 15.10 I observed the same thing and was rebuted with the very same
> arguments of needing to plan ahead.
> 
> You don't even take the time to appreciate what you've done, for a
> certain sense of the word.
> 
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel [1]
> 
> 
> 
> Links:
> ------
> [1] https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel