also sprach Giacomo Catenazzi <cate@debian.org> [2015-09-23 08:43 +0200]:
> But mainly it is because it was a big push from DC15 people to
> avoid -team, and get decision delegations to subteam (which
> indirectly it was done also not to inform entire team, to avoid
> discussions).
This is a misrepresentation of what happened.
We were not the first to steer away from the consensus-driven
approach we had pre-DC10, which more often caused decisions not to
be taken than consensus reached.
We have admitted multiple times that perhaps our biggest mistake was
to cease informing the team about pending decisions, or decisions
made and why they were made. At least I think this was possibly our
biggest mistake.
But part of the reason why we acted this way was because decisions
were challenged too often after they were made, and this just hurt.
In Debian, we can do this, as we have infinite time (the release
team is also pushing to change this, thankfully). But in DebConf, we
really do not have infinite time, and almost always, in such
a situation, any decision is better than no decision.
And the reason we opted to move meetings about mainly local issues
back to the #debconf15-germany channel was because of feedback from
people interested in DC15 who were scared off by the bikeshedding
and behaviour of folks on #dc-team, and by some #dc-team people who
complained about all the backlog about stuff they (rightfully)
didn't care about.
> I’m totally in favour to have more statuses report (not only
> decision taken, but what decision is being considered [which can
> effect other people/tasks/teams]) on -team ML (or IRC), but there
> is huge resistance on that.
Can you identify this huge resistance? What are the arguments by the
people resisting?
> How -team could know the status of video, when shipping discussion
> should be taken (in DC14 the shipping discussion started much too
> late, but thanks Carl we had alternate video materials).
I am on -team and quite frankly, I don't care about when the video
team ships stuff. This is not because I don't value their work, but
mostly because I trust them to do it right, and because I know that
they would turn to dc-team when they thought it was necessary.
> So someone should be in charge to get information from team and
> check if things are working according other team plans. The orga
> (in general) checks this, but it is better to have people
> responsible to this important task.
The information should be provided and fetched directly between the
people involved. Instead of employing a messenger in between, who
would also just look at a timeline and figure out dependencies
between tasks, this timeline and this dependency between tasks
should just be written down somewhere and known by people. Having
a proper project management tool to guide us would really help.
> I’m totally in favour to have more information (and more
> frequent) in -team (the ML). But I think you have read
> this many and many time in past 5 (or more) years, as
> requiring documentation so we know what to do next
> without having to ping people for weeks.
+1. The question is a bit what this documentation should look like.
For decades, we've organised business and government institutions in
departments and given them guidelines how to work within their
cages.
Over the last 20 years or so, this structure, has started to fade,
admittedly slowly — it's completely absent in young companies
nowadays. We see almost exlusively process-based approaches, rather
than approaches based on compartmentalisation of task categories.
So then, the documentation we need is a timeline, and dependencies
between tasks. And to me, this sounds like a project management
tool, as this sort of topologically sorted graph is just hard to
maintain in a wiki.
--
.''`. martin f. krafft <madduck@debconf.org> @martinkrafft
: :' : DebConf orga team
`. `'`
`- DebConf16: Cape Town: https://wiki.debconf.org/wiki/DebConf16
DebConf17 in your country? https://wiki.debconf.org/wiki/DebConf17
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)