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 <[email protected]> wrote: >> >> >>> >>> On 10/16/2012 03:40 PM, Rob Weir wrote: >>> >>>> On Tue, Oct 16, 2012 at 6:06 PM, Kay Schenk <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On 10/16/2012 02:47 PM, Rob Weir wrote: >>>>> >>>>>> >>>>>> On Tue, Oct 16, 2012 at 5:29 PM, Kay Schenk <[email protected]> >>>>>> 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 > >
