Hi,
On Sun, Oct 12, 2014 at 12:35:11AM +0100, Moray Allan 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 )
First of all, I fully agree we need to group teams and organize tasks better.
But I have the impression that there is the idea that having very few big teams
is
going to solve some of the problem we had from having a myriad of small teams.
My comments on the teams:
> Here is an initial draft possible subteam list for further discussion and
> modification:
>
> - Content: schedule scheme, CFP, talk/session selection and scheduling,
> inviting guest speakers, anything related to the content of the conference
If the localteam wants to have a Debian day or similar, related task need
to be included in this team.
> - 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
On-site network should be an independent team coordinating with facilities and
video team. And IMHO, also video team should be independent.
> - Finance: fundraising (intersecting with wider Debian fundraising team),
> budget agreement, accounting, bursaries
This is a strange grouping for me too. Bursaries should be independent. Budget
requires of some work in the beginning that doesn't necessarily need a team.
Once the budget is done and approved, it's a task of the chairs to make changes
or move money from one item to another. It doesn't need to be included in
finance
but it definitively need to be grouped with accounting.
Then fundraising should be another independent team too where everybody is
welcome to help.
> - Participant assistance: frontdesk, registration, visa, volunteer
> recruitment during conference period, answering general requests from
> participants and volunteers.
This one also groups plenty of small things. Frontdesk is a independent team
that only works during DebConf. Registration includes visa and also room
accommodation.
I'm not sure what "volunteer recruitment during conference period" is
but any of the ideas I have fits with the other tasks.
> - 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
Isn't this the work of the chairs? They can get more people helping with this
and make a "coordination" team, sure.
> Notes
[...]
> - 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?).
If you are OK having subteams working as they want, what's the point
of forcing them to be in a bigger team? What matter is this team working
well, the information is transmitted from year to year, the team interacts
with the other teams and the team has a clear lead.
> - 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 disagree with this. You can be good at interacting with sponsors and have
not idea how DebConf uses their money. And the opposite.
> - 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.
As said above, I think video team should be independent from infrastructure.
This team already includes the hardware and video team infrastructure part
tasks that should be coordinated very well, but also has plenty of volunteers
that don't help with the above tasks. With other big tasks being coordinating
all the on-site volunteers.
> Open questions
>
> - What tasks have been forgotten in the list above, and where would they fit
> in?
We'll forget plenty of tasks and some new ones will appear. We need a mechanism
to assign new tasks to a team. On in some cases, to re-assign tasks.
[...]
>
> - 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 like Brian's reply here: 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. The DebConf Committee deserves a whole different discussion. And who belongs
to this committee, if we decide we still need it, should be independent
of the debconf teams.
Ana
_______________________________________________
Debconf-team mailing list
Debconf-team@lists.debconf.org
http://lists.debconf.org/mailman/listinfo/debconf-team
