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 <[email protected]> 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
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel [1]
Links:
------
[1] https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
--
kubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
