KG01 - see comments online On Oct 18, 2012, at 5:24 AM, Kay Schenk <kay.sch...@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.sch...@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.sch...@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.sch...@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
