On Sat, Oct 11, 2014 at 7:35 PM, Moray Allan <mo...@sermisy.org> wrote:
> During the workgroup sessions at DebConf, among other points we agreed that
> we would form clearer subteams for related tasks, and clarify subteam
> responsibilities. These "subteams" would group together related tasks,
> while avoiding overlapping roles between subteams to simplify
> decision-making processes. We agreed that all "global" team members should
> belong to a subteam. (See
> https://wiki.debconf.org/wiki/DebconfOrganizationWorkingGroup#Meeting_.234:_August_30th_2014
> for an outline of the discussion )
>
> The first step in the agreed meta-timeline was to "Agree list of subteams
> and responsibilities" at the start of October. Since this hasn't happened
> yet, let's start a discussion now.
Thank you for working on this. I apologize in advance for the length and
tardiness of my response. Please note there was a lot to cover, so I largely
am sharing initial thoughts. Feel free to push back if you disagree, and I'll
give it more thought. :)
> Here is an initial draft possible subteam list for further discussion and
> modification:
Please remember people can (and almost certainly) be on multiple teams
simultaneously.
> - Content: schedule scheme, CFP, talk/session selection and scheduling,
> inviting guest speakers, anything related to the content of the conference
I think this seems ok. (I wrote a note about the name below.)
> - Facilities: accommodation, food, venue negotiations and venue
> arrangements, including for social events: cheese and wine, formal dinner,
> day trip, and any other semi-formal gathering
Ok.
> - Infrastructure: sysadmin (within DSA as well as debconf.org services,
> website and summit included), on-site network and videoteam
I'd keep sysadmin separate, since it's our DSA equivalent, and largely
does not interact with on-site needs, also our sysadmin needs are filed by
alioth-team, DSA and debconf-sysadmin. (Plus some kgb agents) ;)
Arguably, as time goes on, more and more needs can be met by DSA,
but until then, I think a separate team makes sense.
Network and videoteam being together makes some sense, since
handling video puts the most demands on the network. Personally I'd
lean towards making networking a responsibility of the video team. (If
video team is ok with this.)
> - Finance: fundraising (intersecting with wider Debian fundraising team),
> budget agreement, accounting, bursaries
I'm having difficulty wrapping my head around this. Fundraising should
probably remain it's own team, as it will likely eventually grow into a
Debian fundraising team (with help from auditors who are currently involved
in fundraising from individuals). I think I can see budget agreement and
accounting in one (likely very small) team that should have the name
"Finance", and perhaps the lead of that team would be the DebConf
treasurer? (Perhaps all that's really needed here is a Treasurer and
assistant Treasurer.) This team *might* also be involved in reviewing
contracts, to kind of make sure the risk is in line with what DebConf
is generally comfortable with. Bursaries should be a separate team
as well, as there is next to no overlap in the roles.
> - Participant assistance: frontdesk, registration, visa, volunteer
> recruitment during conference period, answering general requests from
> participants and volunteers.
Ok. I'd might add daytrip/dinner/etc coordination to this bit. Realistically
facilities and this team will likely have to collaborate on these events.
> - Coordination: keeping track of overall timelines (though each subteam
> should also be doing this), "poker" role, watch for problems in subteams --
> this team would include the DebConf chairs as members
Not sure how I feel about this. Is this basically a way to have a "chairs-
helpers" team? Arguably, I think this is one of the roles of the chairs, but
they should be able to get help by adding people to their own team, who
aren't DPL delegates? IE: There doesn't need to be a separate team.
Speaking of chairs. It's kind of been bothering me a bit, that every team
has to select a singular leader, except for the chairs? Might it make sense
for chairs to also have a team-selected lead?
I also think the chairs team should perhaps evolve into a team structured
like others. e.g. - seconds, wizards, and maybe even local rep.
> Notes
>
> - This draft comes from collaborative editing with Tassia and Tincho. But
> we disagree on some minor points in our individual preferred versions. :)
>
> - Each subteam would effectively have its own subteams within it (each
> subteam can organise itself as it wishes) -- no one can be forced to work on
> tasks they're not interested in, and within each subteam we would need
> people to lead on specific tasks. But we agreed in the workgroup sessions
> that we need a more compact list of first-level subteams than at present
> (5±2?).
I'm feeling that we are setting up a bit too deep of a structure, and
would prefer slightly more top-level teams, as it seems we are pushing
together groups that are only superficially related. I've listed my proposed
tweaks above. While certainly 22+ teams is too many. I think 8-12 teams
would be ok.
> - Each of these subteams would include new "local team" members each year
> alongside others with more experience. (At minimum each subteam should have
> one "local team" member as a liaison, but we would expect some of the "local
> team" to be interested in each of these areas anyway.)
Agreed. Thinking more than just a single liaison from bid/local team
will be expected for most teams. Thinking the Facilities team for example,
also fundraising, since we expect roughly half of funds to be raised from
local sources.
> - Fundraising should ideally happen through a shared Debian team, but we
> still need some DebConf people to track it ... and probably need a
> continuing input of DebConf people to work hard to make it happen. At the
> same time, the people who are thinking about DebConf fundraising are usually
> the ones who have the best idea about how we should be budgeting, so it
> makes sense to put these tasks together in a subteam.
I'd say that eventually I'd expect that once the debconf-fundraising
team "grows" into a Debian fundraising team, the appropriate evolution
would be to turn that team into a "Debian team" w/ or w/o a DPL delegation.
(It's unclear to me if a delegation will be helpful.)
> - There is some argument in favour of putting the video team as a first
> level subteam. But this year we had trouble since its
> network/infrastructure needs weren't known and taken into account in time,
> so it perhaps makes sense to put it into a subteam which will aggregate a
> list of our hardware/network needs in advance of the conference period.
Answered above.
> Open questions
>
> - What tasks have been forgotten in the list above, and where would they fit
> in?
I have not really considered this, and am not really qualified to
answer. I think as long as we remain flexible, we can adjust as
we go.
> - Are there tasks you think should be moved between the subteams above/to a
> new subteam?
>
> - Are the subteam names above OK or too neutral so that they aren't
> understandable any more? (Can you think of better ones?)
I second the suggestion for s/Content team/Program team/. I say this because
I think of media/web, when I hear "content".
Most of the other names make sense.. but I think can be optimized, but I can't
think of better names right now. For example "Participant assistance team" is
a bit unwieldy for a team name. I'd almost just call it the "Registration team".
> - Should we have a separate "Communication" team, with {press and PR,
> website content, publishing the CFP and general announcements, dealing with
> feedback@dc}? There could be benefits, but equally I worry about trying to
> create our own version of the Debian publicity team, and about going against
> the "avoid overlapping roles between subteams", since other teams would have
> to work closely with this one if it is to have a real purpose.
I don't think we need a separate comms team, as it would be awkward to have to
proxy requests to debian-publicity through another team. I think for now, let's
keep this duty distributed to have the various subteams work directly with
debian-publicity.
If someone really wants to be a part of this type of team, debian-publicity can
definitely use more volunteers.
> - In the slightly longer term, should we make subteam leads
> automatically/ex-officio become members of the DebConf Committee, for venue
> decisions etc.?
No. I think perhaps it would probably make sense that each subteam lead is
responsible for nominating someone to represent their subteam in the bid
selection process. This could be the subteam lead, or not. This will be useful
in making sure that the selection process considers the individual subteam's
needs. e.g. for fundraising/sponsors team, we'd want to make sure that the bid
teams know that they will be responsible for raising a significant portion of
funds from local sources, and make sure they have done their homework
there.
The main point here is I don't necessarily want to force team leads into doing a
task they might have no interest in doing, so we should give them an option to
appoint someone from their team to the bid selection committee.
I am also a bit confused by some suggestions that the committee should have
other responsibilities other than bid selection? What other roles are
envisioned? (Gunnar mentioned having them be active throughout the year.)
Cheers,
Brian
> --
> Moray
> _______________________________________________
> Debconf-team mailing list
> Debconf-team@lists.debconf.org
> http://lists.debconf.org/mailman/listinfo/debconf-team
_______________________________________________
Debconf-team mailing list
Debconf-team@lists.debconf.org
http://lists.debconf.org/mailman/listinfo/debconf-team
