incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: [DISCUSS] defining roles for management, coordination, work items...
Date Thu, 18 Oct 2012 19:14:23 GMT


On 10/17/2012 10:35 PM, Kevin Grignon wrote:
> KG01 - see comments online
>
> On Oct 18, 2012, at 5:24 AM, Kay Schenk <kay.schenk@gmail.com> wrote:
>
>>
>>
>> On 10/16/2012 03:40 PM, Rob Weir wrote:
>>> On Tue, Oct 16, 2012 at 6:06 PM, Kay Schenk <kay.schenk@gmail.com> wrote:
>>>>
>>>>
>>>> On 10/16/2012 02:47 PM, Rob Weir wrote:
>>>>>
>>>>> On Tue, Oct 16, 2012 at 5:29 PM, Kay Schenk <kay.schenk@gmail.com>
wrote:
>>>>>>
>>>>>> [top posting -- old discussion/business]
>>>>>>
>>>>>> I just created a little wiki schematic page based on this discussion
at:
>>>>>>
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Management+Roles
>>>>>>
>>>>>> which will make it easy for us to add roles, people to roles, etc.
>>>>>> [The second column, intended for actual names, is blank so far.]
>>>>>>
>>>>>
>>>>> I'm not really sure what problem we're solving here.
>>>>
>>>>
>>>> Better defining activities that we do/need to do.
>>>> Hopefully soliciting/inviting individuals to take ownership of some of these
>>>> activities.
>>>>
>>>
>>> But we can have a full list of roles on the wiki, but not define a
>>> single task...   But maybe this is the first step.
>>
>> yes...and an oversight in my initial enthusiasm. Obviously, it is difficult to determine
if any list is sufficient unless the roles are defined. :/
>>
>>
>>
>>>
>>> One way of making this scale and be more self-maintaining is something like:
>>>
>>> 1) Work with Infra to create a new issue tracking DB for the project.
>>> Maybe use JIRA rather than BZ.  This new DB would be for tracking
>>> tasks, not for tracking bugs.   (Why a separate DB?  So we don't drive
>>> QA team crazy.)
>
> KG01 - Rob, I like the idea of a new system that supports scope items in addition to
work items. We could benefit from more PPM tooling.

Kevin--

Maybe you could raise this as an additional issue or a separate 
discussion item, and explain to the community what you mean by this. I 
don't know how many folks involved here know what "PPM tooling" is.

>
>>>
>>> 2) In the database we put in all the tasks that we know needs to get
>>> done, from running a RAT scan before a release, to verifying the new
>>> Norwegian translation, to UX exploration tasks, etc.  There are
>>> probably 100+ tasks that we could think of, more than would be fun to
>>> track on the wiki.
>
> KG01 - In fact, I'm already in the midst of populating a ux opportunity backlog as BZ
does not serve my business needs.
>
>>>
>>> 3) Project members can comment on issues and take ownership of them.
>>>
>>> 4) If a project member is focused deeply on a specific issue, then
>>> they can set themselves as the default "owner" for that issue
>>> category.
>>>
>>> In this way, roles are defined implicitly by what tasks you claim and
>>> what categories you set yourself as the default owner.
>
> KG01 - agreed, less role oriented and more work item oriented.

"work items" pretty much determine role I would think except in some 
specialized cases at Apache.

>
>>>
>>> The nice thing about this approach is it helps with the communication
>>> challenges of a large project.  None of us can read everything on
>>> every mailing list.  But we can all read the JIRA notifications that
>>> come directly to us as an issue owner.
>>
>> Well this part is certainly true. It's difficult to overlook what you signed up for,
when you get notifications.
>>
>>>
>>> Another nice thing about this approach is it lets us set up a backlog
>>> of things that are "nice to do someday" but where we have no
>>> volunteer.  For example, spell checking the website, or updating the
>>> Indonesian translation.  We don't even have a person in the role of an
>>> Indonesian Translator today.  But if the tasks are defined in JIRA
>>> then we can the unassigned tasks as a way to recruit new volunteers.
>>> It makes it easier to see where we need help.
>
> KG01 - backlogs also allow is to create candidate release and iteration plans
>
>>
>> I think the JIRA/BZ approach definitely has merit in the long run.
>> For now, I think it would be advantageous to just flesh out the page a bit more to
supply definitions and see what we're missing in terms of typical actions/roles that we take
on, or should be taken on.
>>
>> And, although people could indeed "enroll" for tasks right on the page, I'm not explicitly
suggesting that as some categories, for example, developer, would have MANY entries. However,
I do think it is valuable for site visitors to at least identify mailing list moderators,
and maybe BZ, wiki, etc. admins.
>>
>>
>>>
>>>>
>>>>>
>>>>> For example, if person X is assigned role Y, I assume we don't want to
>>>>> encourage people to contact person X directly for questions or
>>>>> assistance.  We should do our work on ooo-dev.
>>>>>
>>>>> I assume we also want to avoid the type of hard-coded roles that
>>>>> existed with OOo, where the names, personal email addresses and even
>>>>> phone numbers of community manages, press contacts, etc., were on
>>>>> hundreds of web pages.
>>>>
>>>>
>>>> Well these are good points actually.
>>>>
>>>> Yes, we should absolutely continue discussions on ooo-dev. I was thinking
of
>>>> putting in names for the roles. The "roles" are not "hard" as you suggest
>>>> here. We don't hire people and they don't have "official" positions. Maybe
>>>> more of a way of providing information both to the outside and (P)PMC.
>>>>
>>>>
>>>>>
>>>>> I suggest keeping this light-weight, non-exclusive, open to all who
>>>>> are interested, etc.
>>>>
>>>>
>>>> No problem with that of course. PLEASE self-sign up! This is encouraged!
>>>> I was tempted to assign Juergen permanent "release manager" but thought
>>>> better of it. :}
>>>>
>>>>
>>>>   So more like "areas of interest" or "contact
>>>>>
>>>>> point" rather than hard-coded roles.
>>>>
>>>>
>>>> Well, OK. Still I think explicitly  defining roles is good for the project
>>>> in some ways. It will show us what types of activities "someone" needs to
>>>> take ownership of.
>>>>
>>>>
>>>>    Remember, people do go on
>>>>>
>>>>> vacation, volunteers come and go, real life intervenes.  So we cannot
>>>>> "assign" someone a role in the same way we can an employee.
>>>>
>>>>
>>>> Exactly, we need overlap!
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Rob referenced the following page as part of this thread:
>>>>>>
>>>>>> http://incubator.apache.org/openofficeorg/ppmc-faqs.html#status
>>>>>>
>>>>>> Which probably needs updating or ???? Of course, this is one of the
items
>>>>>> that needs to go in the "Graduation checklist" just started today
as
>>>>>> well.
>>>>>>
>>>>>
>>>>>
>>>>> Note this page as well, which goes in the other direction, mapping
>>>>> person to area:
>>>>>
>>>>> http://incubator.apache.org/openofficeorg/people.html
>>>>>
>>>>> It would suck if we had to track the same information in both places.
>>>>> Maybe there is a way we can track this in one place?
>>>>>
>>>>> Maybe add a "role" column to the "people" page?  I dunno.
>>>>
>>>>
>>>> A good idea as well. We could discuss this...I had actually forgotten all
>>>> about the "people" page :/. Should we keep using it?
>>>>
>>>>
>>>>>
>>>>> -Rob
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On 09/09/2012 11:02 PM, Rob Weir wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Sep 9, 2012, at 2:51 PM, Kay Schenk <kay.schenk@gmail.com>
wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/08/2012 02:15 PM, tj wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/8/2012 13:50, Dave Fisher wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sep 7, 2012, at 6:50 AM, Oliver-Rainer Wittmann
wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I would like to give my thoughts on defining
roles for management,
>>>>>>>>>>> ... as the thread "Specific actions needed for
developing the
>>>>>>>>>>> community" tends to become a general one on this
topic.
>>>>>>>>>>>
>>>>>>>>>>> For me we, the AOO community, need to have an
idea about the
>>>>>>>>>>> different roles which need to be fullfilled to
drive our project:
>>>>>>>>>>> - role of developer
>>>>>>>>>>> - role of forum admin
>>>>>>>>>>> - role of tester
>>>>>>>>>>> - role of UX practitioners
>>>>>>>>>>> - role of release manager
>>>>>>>>>>> - role of community manager
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>       internal / project(?)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - role of marketing person
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>       external / ecosystem(?)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - role of press contact
>>>>>>>>>>> - role of distribution manager
>>>>>>>>>>> - role of buildbot admin
>>>>>>>>>>> - ...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> role of translators (l10n)
>>>>>>>>>> role of infrastructure
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> role of moderators for various MLs
>>>>>>>>> role of Mwiki admin (mostly me, now; help welcome)
>>>>>>>>> role of BZ admin (doing a little of that, just added
Dave McKay)
>>>>>>>>> /tj/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>    From my point of view these are more or less
areas of the project
>>>>>>>>>>> which need to be fullfilled with certain actions
and coordination.
>>>>>>>>>>> What I do not believe is that we need to assign
certain individuals
>>>>>>>>>>> on these roles (*).
>>>>>>>>>>> I agree with J├╝rgen that certain individuals
will grow their
>>>>>>>>>>> expertise in a certain role/area and as a contributor
will take
>>>>>>>>>>> action or raise flag due to lack of resources,
knowlegde, ...
>>>>>>>>>>> I think we already had quite a couple of good
examples for such a
>>>>>>>>>>> habit. But, I also have to admit that for certain
other roles we did
>>>>>>>>>>> not yet succeed as we could and should.
>>>>>>>>>>> And here comes the responsibility of the (P)PMC
- its management
>>>>>>>>>>> duty, if you want. The (P)PMC as a group takes
care that the roles
>>>>>>>>>>> are fullfilled. E.g., by raising a corresponding
gap on ooo-dev, by
>>>>>>>>>>> calling for discussion and volunteers, by leveraging
new and/or
>>>>>>>>>>> established members.
>>>>>>>>>>> My thoughts are also based on the fact that Apache
had only two
>>>>>>>>>>> roles
>>>>>>>>>>> in a project to by assigned to a certain individual
- the PMC chair
>>>>>>>>>>> and the release manager.
>>>>>>>>>>>
>>>>>>>>>>> As pointed out above, I think that we need to
work out the need and
>>>>>>>>>>> the working tasks for certain roles in our project.
This work out is
>>>>>>>>>>> from my point of view a community task which
could or may be should
>>>>>>>>>>> be driven by the current PPMC in order to demonstrate
our
>>>>>>>>>>> self-governance.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This is good. I think that there are four parts in
no particular
>>>>>>>>>> order. We've done a lot of definition already. This
is about
>>>>>>>>>> reorganizing and formalizing the arrangement. Some
of these teams of
>>>>>>>>>> role players will be small and some large.
>>>>>>>>>>
>>>>>>>>>> (1) Defining the role so that any volunteer can know
how to start
>>>>>>>>>> helping.
>>>>>>>>>> (2) Defining who on the (P)PMC will have oversight
with the charge of
>>>>>>>>>> guiding volunteers and identifying committers. This
person should be
>>>>>>>>>> a
>>>>>>>>>> player-coach and not a manager.
>>>>>>>>>> (3) Defining workflow around these roles. Different
sets of roles
>>>>>>>>>> will
>>>>>>>>>> need to work together.
>>>>>>>>>>
>>>>>>>>>>       (A) Developing a Release - developer, tester,
ux, buildbot.
>>>>>>>>>>       (B) Building / Passing a Release - buildbot,
release, community.
>>>>>>>>>>       (C) Distributing a Release - distribution,
infrastructure,
>>>>>>>>>> marketing, press.
>>>>>>>>>>       (D) Supporting Users - forum, tester, ux, community,
marketing.
>>>>>>>>>>
>>>>>>>>>> (4) What infrastructure the role uses.
>>>>>>>>>>
>>>>>>>>>> I think that this should be documented in the incubator
website at
>>>>>>>>>> least for overview and navigation about project roles.
Each group
>>>>>>>>>> that
>>>>>>>>>> self-organizes around a role should use whatever
project resource
>>>>>>>>>> makes sense for them.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Dave
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards, Oliver.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>> This thread is really tremendous work in my opinion! Both
the roles and
>>>>>>>> the workflow groupings!
>>>>>>>>
>>>>>>>> Documenting it on the incubator website would be most excellent.
>>>>>>>>
>>>>>>>
>>>>>>> If someone decides to create a new page for this they should
be sure
>>>>>>> to delete the existing page I created to track admins and moderators:
>>>>>>>
>>>>>>> http://incubator.apache.org/openofficeorg/ppmc-faqs.html#moderator
>>>>>>>
>>>>>>> (or we could just update that page)
>>>>>>>
>>>>>>> Rob
>>>>>>>
>>>>>>>>>>> (*) except the ones for the PMC chair and the
release manager, of
>>>>>>>>>>> course, as they are part of the Apache Way.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>> MzK
>>>>>>>>
>>>>>>>> "We never sit anything out. We are cups, constantly and quietly
>>>>>>>> being filled.  The trick is, knowing how to tip ourselves
over and
>>>>>>>> let the beautiful stuff out."
>>>>>>>>                            -- Ray Bradbury, "Zen in the Art
of Writing"
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------------------------------------------------------
>>>>>> MzK
>>>>>>
>>>>>> "Anyone who considers protocol unimportant has never
>>>>>>    dealt with a cat."
>>>>>>                                  -- Robert Heinlein
>>>>
>>>>
>>>> --
>>>> ------------------------------------------------------------------------
>>>> MzK
>>>>
>>>> "Anyone who considers protocol unimportant has never
>>>>   dealt with a cat."
>>>>                                 -- Robert Heinlein
>>
>> --
>> ------------------------------------------------------------------------
>> MzK
>>
>> "Anyone who considers protocol unimportant has never
>> dealt with a cat."
>>                                -- Robert Heinlein

-- 
------------------------------------------------------------------------
MzK

"Anyone who considers protocol unimportant has never
  dealt with a cat."
                                -- Robert Heinlein

Mime
View raw message