incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Grignon <kevingrignon...@gmail.com>
Subject Re: [DISCUSS] defining roles for management, coordination, work items...
Date Thu, 18 Oct 2012 05:35:42 GMT
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. 

>> 
>> 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. 

>> 
>> 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

Mime
View raw message