Monthly Sprint Proposal

Hi all,

These are some proposed ideas for the issues that I raised during the April
'09 Sprint Meeting on maemo-meeting.

I would assume that logs for this meeting will eventually surface on
maemo.org [1], but I don't see anything for March '09, so maybe not.
[1] (http://maemo.org/maemo-meeting/)

Basically, I got frustrated with trying to read last month's sprint page
[2]; the tasks were a sea of red (meaning "really stuck / delayed") and the
Activity Log was full of stuff that was difficult to tie to the tasks above.

[2] http://wiki.maemo.org/Maemo.org_Sprints/March_09

So I have spent many hours thinking about how it should be done. Then, in
preparation for writing this proposal, I read the maemo.org Sprints page
[3], and I realized that my proposals were mostly what was supposed to be
happening anyway.

[3] http://wiki.maemo.org/Maemo.org_Sprints

So, my proposal will start out with the simple request that the paid
maemo.org team members follow the guidelines on the Sprints page.

Next, I'll make a few suggestions for improving the process. As with all my
"suggestion packages", the ideas can be discarded, modified, or
cherry-picked as desired by those involved.

Here are a few things that I think would make things easier for community
members to follow the progress of maemo.org team members.

(1) Sprint tasks need to be bite-sized. If they will take longer than a
month to accomplish, they should not be sprint tasks; they should be put on
a separate page, "Goals" or "Long-Term Tasks" or something. The sprint tasks
can be broken out of these big goals and as they are achieved, the progress
on the big goals can be updated. The long term goals page can also have some
more explanation as to what these goals are all about. The team members
responsible for the tasks should be responsible for getting this sorted out.

The reason that the sprint tasks need to be bite-sized is because we need to
see some more green on the sprint pages. A long list of stuck tasks is
pretty disenheartening for the community, and it doesn't help the team's
motivation, either.

(2) Activity reports need to be directly tied to sprint tasks. If necessary,
the tasks can be given some sort of ID code, and the activity reports can
just reference the ID code in brackets. If you are doing something that is
related to maemo.org, but isn't a sprint task, then you should probably give
some details about how it relates to one of the long term goals, or how it
relates to your job in general. Some kind of extra explanation would be very
helpful.

If what you did isn't part of a sprint task, but you think it should be,
then I think team members should be able to add tasks mid-sprint, with the
understanding that they'll be carried over to the next sprint, where they
can be discussed more fully (in the review meeting).

(3) All team members should prepare a report at least two days before the
monthly review meeting, and they should publish it somewhere. I suggest this
mailing list, but it doesn't really matter. This report will consist of an
explanation of why sprint tasks didn't get done (the expectation is that the
tasks will get done, since they were chosen to be doable within the sprint,
and if they don't, an explanation is needed), and one or more proposed
sprint tasks for the next sprint. As I suggested in (1) above, these
proposed tasks should be doable in the next month. This report should also
have requests for community help with proposed sprint tasks. The report can
contain anything extra that the team member would like to discuss at the
sprint meeting, too.

In closing, I want to ask that the paid maemo.org team members stay
connected with the community, since they are employed by the community (even
though they are paid by Nokia). Personally, I would really appreciate seeing
them more often over in the forums, mainly because that is the place where I
"hang out" most often.

Ok, there's my "bit". Discuss!
--
Qole: fanboy, wacko, and maemo.org junta member

Hi!

ext Qole wrote:
> Ok, there's my "bit". Discuss!

/me presses Thanks button. ;)

I'm happy to see you reaching exactly the same conclusions I got and
raised when I was kind of chairing that process.

About the maemo.org paid contributors, I want to stress that Tero or
myself from Nokia are not managing them. We are not their bosses and we
don't control what are they doing every day. Public reporting is the
only way they have to explain what are they doing and that reporting is
basically for the community.

Nokia has an overall budget for maemo.org and a big % of that money goes
to pay the salaries of these qualified professionals. Ultimately it is
up to you to decide the tasks, the profiles and even the people that
should be assigned to make the most of that budget.

I'm not saying they are doing bad (actually I think they are doing
good!) but it is good that you watch out and request good reporting and
communication. Don't expect Nokia to raise a yellow/red card if someone
is not doing the type, amount or quality of work is supposed to do. And
think that when it's the time for contract renewals (every six months)
Tero will basically come to you (the council) and ask whether you are
happy or not in order to proceed.

--
Quim Gil
open source advocate
Maemo Software @ Nokia

2009/4/7 Qole <qole.tablet@gmail.com>:
>
> So, my proposal will start out with the simple request that the paid
> maemo.org team members follow the guidelines on the Sprints page.

I agree its disheartening to see a sea of red - and greater discipline
by the review team (Nokia, the maemo.org staff, the council) in
accepting tasks with a clear "is it done: yes/no?" and realistic
"bite-sized" (as you call them) tasks - would definitely help.

I think we need to be careful using terms like "police" and "boss",
though. The point of an agile process like this is that people choose
their tasks based on what they're interested in: this creates buy-in
and will result in a greater commitment to achieving those tasks.

Of course, there are times when there's some drudgerous task to be
done; and the tasks can't be freely choosable ("this month I'm going
to work on my tan") - but this is where having a planning meeting, and
achieving consensus will help.

I believe that the *paid* staff are professional enough to achieve
that, without having to break the process and have something *assign*
tasks to them.

When it comes to volunteers committing tasks to a sprint, we (meaning
the regular attendees to the sprint meetings) can try and suggest that
a task gets split up if we think it's too large to encompass in a
month, or doesn't have a clear target for being met.

It is interesting to me that many of the issues you raise are the
exact same ones I've seen before (in my professional capacity) in
agile processes; and the recommendations you make certainly overlap
with what we've found to be effective:

* Split out tasks - each task should either be "done" or "not done"
at the end of the month.

* Activity logs - stand-up meetings or diaries. I suspect there's
some formatting work we can do to make the maemo.org ones more
accessible (and linking in to ongoing roles - or specific tasks -
may help).

* Prioritisation - things always crop up which are part of a role
which aren't part of a specific task (i.e. p1 bugs in the website,
small packages needing attention, etc.). This is where MoSCoW can
come in:

http://en.wikipedia.org/wiki/MoSCoW_Method

Once all the tasks have been identified, they are given priorities
of around 60% budget on "must", 20% "should" and 20% "could".
When they are tackled in order, the "could" tasks drop out
first when disrupting events occur.

The latter may help with the "explain why a task wasn't completed":
the only things which should need real explanations (from _anyone_
who's *committed* themselves to a task) are "must" and, probably,
"should" tasks.

The big problem here is to limit the administrative overhead for
unpaid community members who are doing things in their spare time.
There are obvious benefits to the *paid* staff of some kind of
improved process (it gives them something to point to at contract
renegotiation time), and there *are* benefits to the community as
well. But the overhead shouldn't detract people from doing "real" work
in the community - especially when it eats up into their spare time.

The advantage of an agile methodology is it allows you to pick and
choose, and react to external factors quickly. If the process needs
tweaks, and we can get consensus on what those tweaks are, there's
nothing stopping us. So, I'd especially like to hear the thoughts of
the "maemo.org four", Henri, Quim and Tero and any lay-people who've
committed tasks to the sprint process.

Cheers,

Andrew

--
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org/
Maemo Community Council chair

On Apr 7, 2009, at 7:52, Qole wrote:

> Hi all,
>
> These are some proposed ideas for the issues that I raised during
> the April '09 Sprint Meeting on maemo-meeting.

Since we are doing smaller bite-sized chunks, I am going to do a short
email addressing one point at a time.

> (3) All team members should prepare a report at least two days
> before the monthly review meeting, and they should publish it
> somewhere.

I have a great deal of reporting already extant. For example;

- I report my hours and tasks to my immediate employer ResourcePoint AB
- I create a detailed report of work done to Nokia bi-weekly since
they are a public company
- I put those details on the wiki for the community to review daily
or every other day

The request for another report seems redundant.

Jeremiah

Hello,

On Apr 7, 2009, at 8:20, Quim Gil wrote:

> when it's the time for contract renewals (every six months)
> Tero will basically come to you (the council) and ask whether you are
> happy or not in order to proceed.


You have an obligation to be a bit more formal than that.

The professionals who work on maemo.org work very hard, they deserve
the courtesy and respect of being treated with professionalism. For
example, the virtual machine which runs garage.maemo.org is heavily
burdened and has spikes in polling making it hard to administer. I
think Niels does an amazing job keeping it running and available to
the community, but that might not be visible to the council since they
do not log in to the server and do actual work there.

Turning to the council for a judgement of people's performance leaves
lots of room for personal opinions and unprofessional appraisals, this
will almost certainly be an area of contention that will require
delicate handling.

What you both (qole and Quim) seem to forget is that there are people
in these positions. Neither of you are being particularly professional
in your ad hoc decision making. I strongly encourage both of you to
think about the people involved, how to clearly define the roles so
that those in them understand their responsibilities and can execute
them, and to clearly define the roles and obligations of the council
vis-a-vis the maemo.org staff.

If you want greater transparency and accountability, you need to
assume greater responsibility for that to happen.

Jeremiah

Hi,

I don't think the main issue is _our_ (or even the community's)
perception of maemo.org employee performance. I think it is all about
giving the community something that they can look to and easily
see/discern that progress is being made.

Of course, a lot of argument can be made about how the community doesn't
really need to see any of that -- they're not "paying" for the service
after all. Unfortunately, everyone involved desires to see an open
community where the "backbone" is always visible -- and always working.
(Some would call this a mistake, but I think it's one of the values that
drives maemo.org's success).

So, all of this reporting, isn't really to assess performance (well, ok,
it really will help with that too), but more to appease a hungry
community who has been bred by this philosophy of openness.

On a related, but slightly different note, I was wondering if something
like Bugzilla (or other) would be beneficial in
creating/logging/tracking Sprint tasks. Any opinions?

Tim



Jeremiah Foster wrote:
> Hello,
>
> On Apr 7, 2009, at 8:20, Quim Gil wrote:
>
>> when it's the time for contract renewals (every six months)
>> Tero will basically come to you (the council) and ask whether you are
>> happy or not in order to proceed.
>
>
> You have an obligation to be a bit more formal than that.
>
> The professionals who work on maemo.org work very hard, they deserve
> the courtesy and respect of being treated with professionalism. For
> example, the virtual machine which runs garage.maemo.org is heavily
> burdened and has spikes in polling making it hard to administer. I
> think Niels does an amazing job keeping it running and available to
> the community, but that might not be visible to the council since they
> do not log in to the server and do actual work there.
>
> Turning to the council for a judgement of people's performance leaves
> lots of room for personal opinions and unprofessional appraisals, this
> will almost certainly be an area of contention that will require
> delicate handling.
>
> What you both (qole and Quim) seem to forget is that there are people
> in these positions. Neither of you are being particularly professional
> in your ad hoc decision making. I strongly encourage both of you to
> think about the people involved, how to clearly define the roles so
> that those in them understand their responsibilities and can execute
> them, and to clearly define the roles and obligations of the council
> vis-a-vis the maemo.org staff.
>
> If you want greater transparency and accountability, you need to
> assume greater responsibility for that to happen.
>
> Jeremiah
>

--
http://tim.samoff.com

On Apr 7, 2009, at 9:57, Andrew Flegg wrote:

> 2009/4/7 Qole <qole.tablet@gmail.com>:
>>
>> So, my proposal will start out with the simple request that the paid
>> maemo.org team members follow the guidelines on the Sprints page.
>
>
> I think we need to be careful using terms like "police" and "boss",
> though.

I agree.

>
> It is interesting to me that many of the issues you raise are the
> exact same ones I've seen before (in my professional capacity) in
> agile processes; and the recommendations you make certainly overlap
> with what we've found to be effective:

This kind of perspective is invaluable, it strengthens the maemo
development process.

>
> * Split out tasks - each task should either be "done" or "not done"
> at the end of the month.
>
> * Activity logs - stand-up meetings or diaries. I suspect there's
> some formatting work we can do to make the maemo.org ones more
> accessible (and linking in to ongoing roles - or specific tasks -
> may help).
>
> * Prioritisation - things always crop up which are part of a role
> which aren't part of a specific task (i.e. p1 bugs in the website,
> small packages needing attention, etc.). This is where MoSCoW can
> come in:
>
> http://en.wikipedia.org/wiki/MoSCoW_Method
>
> Once all the tasks have been identified, they are given priorities
> of around 60% budget on "must", 20% "should" and 20% "could".
> When they are tackled in order, the "could" tasks drop out
> first when disrupting events occur.
>
> The latter may help with the "explain why a task wasn't completed":
> the only things which should need real explanations (from _anyone_
> who's *committed* themselves to a task) are "must" and, probably,
> "should" tasks.
>
> The big problem here is to limit the administrative overhead for
> unpaid community members who are doing things in their spare time.
> There are obvious benefits to the *paid* staff of some kind of
> improved process (it gives them something to point to at contract
> renegotiation time), and there *are* benefits to the community as
> well. But the overhead shouldn't detract people from doing "real" work
> in the community - especially when it eats up into their spare time.
>
> The advantage of an agile methodology is it allows you to pick and
> choose, and react to external factors quickly. If the process needs
> tweaks, and we can get consensus on what those tweaks are, there's
> nothing stopping us. So, I'd especially like to hear the thoughts of
> the "maemo.org four", Henri, Quim and Tero and any lay-people who've
> committed tasks to the sprint process.

I think this is worth a try, it sounds workable.

Jeremiah

On Tue, 2009-04-07 at 08:01 -0500, Tim wrote:
> On a related, but slightly different note, I was wondering if something
> like Bugzilla (or other) would be beneficial in
> creating/logging/tracking Sprint tasks. Any opinions?

We here, at my company, use a bug/feature tracking solution exclusively
with the sprint/agile method. Works very well and enables us to make
pretty accurate estimations as well as keep track of individual tasks.

> Tim

Regards,
Jamie.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAknbT98ACgkQGfHkJ76hZ0eKwQCgvUvzfbuhju7kjfZqifYLHqtF
euUAnixwmxMP8fHvK7IPnLLIUdUsWKbl
=QBXq
-----END PGP SIGNATURE-----

Hi,

ext Jeremiah Foster wrote:
> Hello,
>
> On Apr 7, 2009, at 8:20, Quim Gil wrote:
>
>> when it's the time for contract renewals (every six months)
>> Tero will basically come to you (the council) and ask whether you are
>> happy or not in order to proceed.
>
>
> You have an obligation to be a bit more formal than that.
>
> The professionals who work on maemo.org work very hard, they deserve
> the courtesy and respect of being treated with professionalism.

I think I'm being as formal as you can be. And I think the way of
working described proofs how big is our respect to your professionalism,
and to the seriousness of the council as well.

Nokia would not fund full community salaries in these times when so many
corporate salaries are being cut and it wouldn't have the amount of
trust is putting on the maemo.org team and the council if we wouldn't
believe that you are professional, responsible and able to manage that work.

Maybe someone thinks that just because Nokia is a big company we can
throw away money in whatever makes the community feeling good. No,
people like Tero or myself are accountable of the results obtained with
the budget invested in maemo.org. We could have tried a path of
micromanagement treating the maemo.org team just as Nokia employees at
our service that happen to work out of our premises. Instead we have
decided to go for the path of 'liberating community members', letting
them work based on the tasks and agenda agreed between themselves and
the community.

The fact that the community (represented by the council) is ultimately
who evaluates that work is just a consequence of that. Of course Tero
and myself are following what you do and of course we expect
professionalism, deliveries and solutions to the most urgent and
important problems. We will raise the flag if we see something is
utterly suspicious or wrong. But I'm certain is the community (council)
who ultimate decides.

Some examples to be more clear:

- The council hired you, Jeremiah. They asked for our opinions but they
decided to hire you. It makes sense that they are the ones deciding
whether you have worked according to the expectations when hired or not.

- Imagine the council liked you a lot but we at Nokia thought you
contract should not be renewed. What kind of emancipated community would
allow them Nokia to have the veto?

- Imagine the council disliked you a lot but we at Nokia actually liked
your work. They don't want to renew you but we want? Same question as
above + how comfortable and efasible would be your work at the end when
everybody knows you are 'the guy Nokia wanted to be in the post'?

- Look at Stormy Peters, executive director of the GNOME Foundation. She
was hired by the foundation board (equivalent to our council) but she is
paid with the funds donated by the advisory board companies (that in our
case would be Nokia). It's the board who decides whether Stormy gets
renewed or not, and any veto coming from any company in the advisory
board (or all of them) would be probably considered a corporate
interference in the community life.


> For
> example, the virtual machine which runs garage.maemo.org is heavily
> burdened and has spikes in polling making it hard to administer. I
> think Niels does an amazing job keeping it running and available to
> the community, but that might not be visible to the council since they
> do not log in to the server and do actual work there.

The work is visible to the council and whoever if you report it. Just
like you just did in these 5 lines. That's the whole point of this thread.

> Turning to the council for a judgement of people's performance leaves
> lots of room for personal opinions and unprofessional appraisals, this
> will almost certainly be an area of contention that will require
> delicate handling.

Only if you think the council is opinionated and unprofessional. If we
would think so we wouldn't give them such decision, nor the trust and
exposure we are giving them in other areas.

"Every country has the government it deserves", says an adagio in
international politics. It can be translated to free software community
projects as well. We believe the Maemo community is good-willing and
mature enough to have a mature and good-willing council.


> What you both (qole and Quim) seem to forget is that there are people
> in these positions. Neither of you are being particularly professional
> in your ad hoc decision making. I strongly encourage both of you to
> think about the people involved, how to clearly define the roles so
> that those in them understand their responsibilities and can execute
> them, and to clearly define the roles and obligations of the council
> vis-a-vis the maemo.org staff.
>
> If you want greater transparency and accountability, you need to
> assume greater responsibility for that to happen.

I wasn't asking for greater transparency and accountability for Nokia,
but for the whole community (including Nokia).

I don't think the community (including Nokia) forgets that the maemo.org
team is made of people (on the contrary, you are getting much more
personal trust, understanding and appraisal an average employee would
get in an average corporate job).

I think roles and obligations need to be defined, just not by Nokia only
and directly. The maemo.org team and the council (again, as
representatives of the community) are the ones driving that. We follow
and say whatever we feel like saying.

Sorry if my email was misinterpreted. I hope you don't feel unvalued and
ignored, because actually we think the maemo.org team and the way it
works is one of the most valuable things this community has.

--
Quim Gil
open source advocate
Maemo Software @ Nokia

On Apr 8, 2009, at 9:25, Quim Gil wrote:

> Hi,
>
> ext Jeremiah Foster wrote:
>> Hello,
>>
>> On Apr 7, 2009, at 8:20, Quim Gil wrote:
>>
>>> when it's the time for contract renewals (every six months)
>>> Tero will basically come to you (the council) and ask whether you
>>> are
>>> happy or not in order to proceed.
>>
>> You have an obligation to be a bit more formal than that.
>>
>> The professionals who work on maemo.org work very hard, they deserve
>> the courtesy and respect of being treated with professionalism.
>
> I think I'm being as formal as you can be.

In what way exactly? Can you point to processes and documentation that
might point to the formal relationship between the council and the
paid staff? Formal processes for defining the roles and
responsibilities of the paid staff?

> And I think the way of
> working described proofs how big is our respect to your
> professionalism,
> and to the seriousness of the council as well.
>
> Nokia would not fund full community salaries in these times when so
> many
> corporate salaries are being cut

<snip>

> We will raise the flag if we see something is
> utterly suspicious or wrong. But I'm certain is the community
> (council)
> who ultimate decides.
>
> Some examples to be more clear:
>
> - The council hired you, Jeremiah. They asked for our opinions but
> they
> decided to hire you. It makes sense that they are the ones deciding
> whether you have worked according to the expectations when hired or
> not.

This is clear in no uncertain terms, and is as it should be. But this
also describes a two way street - if the council takes on the
responsibility of hiring a person, they have the obligation to fulfill
their end of the bargain and not change terms and conditions with a
new council. This is exactly what is happening now. When Alan writes
"I'm still unclear about the council's role in "policing" the paid
maemo.org team. To what extent are we the team's "bosses"?" he is
pointing to the lack of a clearly defined relationship between the
employer and employee. That relationship must be formalized before
there is hue and cry about "performance concerns, etc..."
"staying on task".

This ought to be obvious to all concerned - before you can hold
someone accountable, you need to define their responsibilities.

The current council is ignoring this and looking for ways to "police"
and "boss" before the roles are defined. This is an abrogation of the
agreement with the previous council, even if that agreement was
implicit and poorly defined. It is also an implicit criticism of the
paid staff and of the previous council, for some reason Alan feels
that the staff need to "stay on task" and need "policing". This is
more than poor language choice, it points to the desire for hierarchy
in what is traditionally a flat organizational structure.
>
> - Imagine the council liked you a lot but we at Nokia thought you
> contract should not be renewed. What kind of emancipated community
> would
> allow them Nokia to have the veto?
>
> - Imagine the council disliked you a lot but we at Nokia actually
> liked
> your work. They don't want to renew you but we want? Same question as
> above + how comfortable and efasible would be your work at the end
> when
> everybody knows you are 'the guy Nokia wanted to be in the post'?

Isn't incumbent on the council, Nokia and the employee to come to an
agreement _beforehand_ about how to meditate these type of disputes?

> - Look at Stormy Peters, executive director of the GNOME Foundation.
> She
> was hired by the foundation board (equivalent to our council) but
> she is
> paid with the funds donated by the advisory board companies (that in
> our
> case would be Nokia). It's the board who decides whether Stormy gets
> renewed or not, and any veto coming from any company in the advisory
> board (or all of them) would be probably considered a corporate
> interference in the community life.

I strongly suspect the board is governed by the corporate laws in the
country in which it is chartered. I strongly suspect her job is
protected by labor laws, a contract, formal agreements, etc. Oughtn't
those hired by the council have the same rights and responsibilities
as their peers in the free software ecosystem?
>
>> Turning to the council for a judgement of people's performance leaves
>> lots of room for personal opinions and unprofessional appraisals,
>> this
>> will almost certainly be an area of contention that will require
>> delicate handling.
>
> Only if you think the council is opinionated and unprofessional.

In some instances the council has been unprofessional, so yes, I do
think that.

> If we
> would think so we wouldn't give them such decision, nor the trust and
> exposure we are giving them in other areas.
>
> "Every country has the government it deserves", says an adagio in
> international politics. It can be translated to free software
> community
> projects as well. We believe the Maemo community is good-willing and
> mature enough to have a mature and good-willing council.

Excellent. By that adagio we will have the council we deserve;
professional, courteous, and committed to the interests of the
community. I think we as a community need to work for that.
>
>> What you both (qole and Quim) seem to forget is that there are people
>> in these positions. Neither of you are being particularly
>> professional
>> in your ad hoc decision making. I strongly encourage both of you to
>> think about the people involved, how to clearly define the roles so
>> that those in them understand their responsibilities and can execute
>> them, and to clearly define the roles and obligations of the council
>> vis-a-vis the maemo.org staff.
>>
>> If you want greater transparency and accountability, you need to
>> assume greater responsibility for that to happen.
>
> I wasn't asking for greater transparency and accountability for Nokia,
> but for the whole community (including Nokia).
>
> I don't think the community (including Nokia) forgets that the
> maemo.org
> team is made of people (on the contrary, you are getting much more
> personal trust, understanding and appraisal an average employee would
> get in an average corporate job).

I would like to directly contradict this statement by pointing to my
personal experience as a professional software developer for Ericsson
at the Linux Development Center in Stockholm. There the personal trust
was significantly higher from project managers than I have experienced
from the current council, appraisals were a formal process based on
the job description, and understanding of our position was part of the
project manager's job - they spent a great deal of resources making
sure we could do our job.

To say I get "much more" of those things from the community and Nokia
is not factually correct, especially after statements like this;
"<qole> I agree that the paid people should work for the community. So
that means that the Council is the "boss" of the paid team, as elected
representatives of the community. I'm just looking for a word that
conveys the "buck stops here" role, when there are performance
concerns, etc..."

Surely you agree that is a direct questioning of the performance of
the paid staff?
>
> I think roles and obligations need to be defined, just not by Nokia
> only
> and directly. The maemo.org team and the council (again, as
> representatives of the community) are the ones driving that. We follow
> and say whatever we feel like saying.

I agree with this completely, we all need to be more active and
involved in defining the community so we can move forward we the
things we love to do and not get bogged down in what Ian Murdoch calls
"process run amok."
>
> Sorry if my email was misinterpreted. I hope you don't feel unvalued
> and
> ignored, because actually we think the maemo.org team and the way it
> works is one of the most valuable things this community has.

I don't think I misinterpreted your email, at least I hope not, please
correct me if I am wrong. I have not felt undervalued by you Quim, on
the contrary. I feel you have, along with Tero, done a remarkable job
shepherding the resources of one of the largest corporations in the
world into a vibrant community with some exceptional people. What
Nokia is doing is an experiment - it is taking on the distributed
software development model of the open source world and energizing
that with resources and openness, there are no real roadmaps for this
and that it functions so well is a testament to the members of the
community and in no small part those from the Nokia side who advocate
inside Nokia for the community. In particular I think Jaffa has done
an excellent job - he and I may disagree, but he takes issues
seriously and listens. Tim, Kees, Stskeeps, qwerty, Niels and others
have been excellent colleagues, the community is enriched by these
people.

I am thrilled to be a part of it.

Jeremiah