Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of kevingrignon.oo@gmail.com
 designates 209.85.213.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5080550F.6040107@gmail.com>
References: <5049FB92.6090802@googlemail.com>
	<CC73C589-EAF8-4EEE-8A21-9BE3448F1890@comcast.net>
	<504BB57D.8040007@apache.org>
	<32341571.21720.1347238326844.JavaMail.mobile-sync@iccag8>
	<2668894498077507778@unknownmsgid>
	<507DD1A0.9090703@gmail.com>
	<CAP-ksohXksn=U4zcs4zzxT9U24FKGmDx=mwYFN7kMyDdoBGKTg@mail.gmail.com>
	<507DDA77.7020907@gmail.com>
	<CAP-ksoiMAE4bWyRgn70R37qA-2Tjnty7DTyHxRoQs+WqWRWviw@mail.gmail.com>
	<507F2228.9070308@gmail.com>
	<313C53A7-CF2A-4DA2-8EF9-ABCA11B0800E@gmail.com>
	<5080550F.6040107@gmail.com>
Date: Mon, 22 Oct 2012 16:00:17 +0800
Message-ID: 
 <CAO4+hqNGNWwYV5NJ9diDGZ1C5vSBECrPAN_DDaj0x=oF7GUZGg@mail.gmail.com>
Subject: Re: [DISCUSS] defining roles for management, coordination,
 work items...
From: Kevin Grignon <kevingrignon.oo@gmail.com>
To: "ooo-dev@incubator.apache.org" <ooo-dev@incubator.apache.org>
Content-Type: multipart/alternative; boundary=20cf3010e50186cd1004cca13e20

--20cf3010e50186cd1004cca13e20
Content-Type: text/plain; charset=ISO-8859-1

On Friday, October 19, 2012, Kay Schenk wrote:

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


KG02 - PPM = project and portfolio management. The PPM process include
objects for scope and work. Some change management systems that manage work
items realize the PPM conceptual model.

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


KG02 - Not necessarily, many work items are boundary objects that apply, or
could be performed by a variety of role.  My previous comment was to
encourage us to focus on work and tasks, and focus less on role.

>
>
>
> 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<http://incubator.apache.org/openofficeorg/ppmc-faqs.html#status>
>
> Which probably needs updating or ???? O
>
>

--20cf3010e50186cd1004cca13e20--