also sprach Giacomo Catenazzi <c...@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 <madd...@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
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
_______________________________________________ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
