New roles in the Ubuntu IRC team

[Alex Harkema]

I agree, very clever idea to share both workload and responsibility.
Op 25 okt. 2011 10:28 schreef "Jussi Kekkonen" <tmt at ubuntu.com> het
volgende:

> +1 for Juha on this, especially on sharing workload etc
>
> On 25 October 2011 11:15, Juha Siltala <juha at siltala.net> wrote:
> > Hi,
> >
> > On Tue, Oct 25, 2011 at 04:22, Benjamin Kerensa <bkerensa at gmail.com>
> wrote:
> >> Could a term other than "Champions" be used? To me Champions seems a tad
> >> elitist and may make other contributors feel that their contributions
> are
> >> not as important since they are not "Champions"
> >
> > Certainly, the term is not important at all. There are examples of a
> > similar levels of delegation, like the "Linus's lieautenants" term
> > that was fashionable when the Linux project famously added a level of
> > "hierarchy" to their organization during the "Linus doesn't scale"
> > incident. Borrowing military terms is not something I'm a big fan of
> > though. Another term that comes to mind is "maintainer", borrowed from
> > the software side. However, that smells like a higher level of
> > resposibility and stress than we probably mean here.
> >
> > In general, I like Jussi's suggestion, and would like to name a few
> > benefits we could gain:
> >
> > * The people who notice first when things need action are not usually
> > the IRCC but team members who are already working in the affected area
> > of our work. This is especially true if Council members opt to step
> > back from active op duties as is advisable in order to ensure
> > neutrality.
> >
> > * This could enhance team spirit and sense of involvement and
> > empowerment within the team.
> >
> > * Simply and practically, larger "administrative" workforce which
> > would lighten everybody's load.
> >
> > When there is more work than the current system can handle, delegation
> > is a sensible thing to do. It is quite clear that things are currently
> > done too slowly and sometimes issues linger for unacceptable lengths
> > of time.
> >
> > The IRCC should of course still remain responsible for the team, and
> > answerable to the CC just as it is now. This would be about enhancing
> > our organization of work, not about the IRCC dodging responsibility.
> >
> > Juha
> >
> >>
> >> On 10/24/2011 11:49 AM, Jussi Schultink wrote:
> >>>
> >>> Hi all,
> >>>
> >>> One of the criticisms the IRCC has received recently is the lack of
> >>> interaction with the IRC team in terms of decision making, as well as
> >>> the lack of things getting done. There has been a lack of teamwork to
> >>> get things done, as well as a lack of communication.
> >>>
> >>> I would like to propose some new roles within the IRC team to help get
> >>> more stuff done that also have the added benefits of communication
> >>> improvement and teamwork.
> >>>
> >>> I would like to see "champions" for several areas that need taking
> >>> care of within the team. These "champions" would be responsible for
> >>> awareness in the team of their area, as well as ensuring tasks get
> >>> followed up on. (the champion doesn't have to do all the work, just
> >>> ensure that it gets done)
> >>>
> >>> The champion would also have a lot of input into the overall direction
> >>> of what happens with that area of the IRC team, thus these roles would
> >>> give people an opportunity to have a real impact on the team and its
> >>> direction. There could be more than one champion for each role.
> >>>
> >>> I would propose the following areas to have champions, but please feel
> >>> free to suggest other areas - especially if you are willing to take up
> >>> the role.
> >>>
> >>>  *Bots&  bot direction (Specifications, idea management, perhaps some
> >>> implementation)
> >>>  *Ban list maintenance/eir care (everybody would be still responsible
> >>> for bans, but this person would be ensuring the ban list does not get
> >>> overfull, ensuring new ops get proper eir training, following up on
> >>> any bugs in eir)
> >>>  *Documentation review (reviewing the wiki and other documentation on
> >>> a regular basis)
> >>>  *Channel list review (Reviewing the channel list of our namespace
> >>> channels for stale and/or inappropriate channels)
> >>>  *Factoid Maintenance and review (reviewing factoids and checking for
> >>> old and outdated factoids on a regular basis, updating factoids).
> >>>  *Policy review (reviewing policies for efficiency, usefulness,
> >>> scale-ability, suggestions of changes to policy)
> >>>
> >>> Again, I want to stress that the champion doesn't need to do all the
> >>> work, just follow up and ensure it gets done.
> >>>
> >>> Also, as part of this, I would like to change the IRCC meeting name to
> >>> IRC Team meeting, and have the champions be a part of the meeting when
> >>> appropriate, to bring things that need changing to the attention of
> >>> the IRC team and the IRC council.
> >>>
> >>> The IRC Council's role in all of this would be to approve changes to
> >>> policy and set out a long term plan for growth and maintenance of the
> >>> IRC team, in consultation with the IRC team and the champions.
> >>>
> >>> I would like to hear all constructive thoughts on this route, be they
> >>> positive or negative.
> >>>
> >>> I would like this to be a part of our long term plans to be discussed
> >>> in the UDS, following discussion on the mailing list and hopefully
> >>> also in the next IRCC meeting this Sunday.
> >>>
> >>> BR
> >>>
> >>> Jussi
> >>>
> >>
> >>
> >> --
> >> Sincerely,
> >>
> >> Benjamin Kerensa
> >>
> >>
> >> --
> >> Ubuntu-irc mailing list
> >> Ubuntu-irc at lists.ubuntu.com
> >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-irc
> >>
> >
> >
> >
> > --
> > Juha Siltala
> >
> > --
> > Ubuntu-irc mailing list
> > Ubuntu-irc at lists.ubuntu.com
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-irc
> >
>
>
>
> --
> Jussi Kekkonen, Tm_T
>   Ubuntu/KDE developer  tmt at ubuntu.com
>
> --
> Ubuntu-irc mailing list
> Ubuntu-irc at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-irc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-irc/attachments/20111025/8d86d619/attachment.html>