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 Wed, 17 Oct 2012 21:24:56 GMT


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

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