Re: [Debconf-team] DC15 wrap-up blog post
also sprach Brian Gupta brian.gu...@brandorr.com [2015-08-29 05:57 +0200]: Thanks Martin! First pass, please feel free to reject my patch in part or in whole. (I didn't want to overwrite the titanpad, so you can go through and pick and choose which bits you want to take. (Some of my sentences may not quite be proper written English, as it's late here.) Very nice. I've completely merged your patch. https://titanpad.com/dc15-wrapup-blogpost I'll try to finish this up today, send a final draft, and then out it goes tomorrow. -- .''`. 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
Re: [Debconf-team] Patch to DebConf orgateam structure
Hi, Thanks for the reply. Having read this, I think that the problem lies at what each of us identifies as local team, we are clearly thinking of different things. I wish we could have had this discussion at DebConf. When I say that there should be a local team, it does not mean that members of the local team cannot participate in the global team. Of course, each and everyone of the members of DC16 organization that were present at DC15 (or previous DebConfs, but I think all of them were at DC15) are -in my vision- both part of the local and the global team. When I advocate for the local team it's not for these people, but for the volunteers that will show up along the way. For those volunteers, joining debconf-team is traumatic. There's too many flamewars, too many things going on at the same time, and they have no idea how to fit into the already existing structures, they just want to help. I've heard this comment many times in the past, and even this year, from people that had been part of Debian for a long time, but had no idea how flamewary debconf-team was. We need those volunteers, we need to be able to delegate stuff towards them, otherwise the DC16 organizing team has too big of a burden. But asking those volunteers to join debconf-team, follow the tons of discussions, follow the IRC meeting on #debconf-team, etc, has been proven to be too much. They just don't, which makes it much harder to integrate them so there's a high chance that you'll lose them. Of course, if any new recruits that join that local team feel like they want to integrate into the global structure they are totally welcome to join. It's not like being part of the local team precludes taking part in content, fundraising, or any other teams. It's just that it's not a pre-requisite to understand and fit into the structure in order to volunteer for working towards DC16. In my experience, the group of local volunteers will form whether you want it or not. This year we operated under the there is no local team rule, and we still had plenty of people that helped and showed up only because it was in Germany. Some of them went away because they didn't feel like they fit into the structure, and plenty of them stayed even though they were not part of any of the official teams. The point is that this local team existed even if it was not allowed to exist according to the structure. This will happen for DC16 as well. There will be Southafricans that will join the team and want to help. The easier you make it for them to *belong*, the more motivation and energy they will have to work on DC16. On Sat, Aug 29, 2015 at 1:52 AM, Allison Randal alli...@lohutok.net wrote: - Another supporting reason was to clearly define who would be working on social activities like the day trip and evening events, but there's no reason that has to be exclusively local people, so it made more sense to just create a Social Activities team. We had a similar conversation around budget and facilities, where it makes more sense to combine people with varying levels of experience and proximity, rather than artificially segmenting the work. I don't object to these new teams. I just want to point out that the intention of the original team structure was to ensure that people stayed on the teams through the years. These teams will have an extremely high turn-over (i.e. most members will only be members for one DebConf). In my original proposal, only the local team would have such a high turnover, but I'm fine with accepting that there's a bunch of teams in the same situation. These teams do not solve the problem described above, local volunteers still need to figure out which team out of Facilities, Social Activities or Finances they fit in, and that's already a rather high barrier for new recruits. There are also many local tasks that don't fit that structure, like: visa help, child care, printing t-shirts, documenting how to go from the airport to the venue, documenting things that people need to remember before travelling, publicizing the open part of the event in local places, and many others. Chill out, feel the beat of the African drums, pour a glass of Pinotage, and join the fun. It's going to be a great year. :) I don't doubt this, every year DebConf is a great even despite all the flamewars that go on through debconf-team. But this doesn't mean that there are no things that we can learn from past experience. My main point is: the less you delegate, the more you burn out; you need a large team in order to delegate to them, so it makes no sense to make it hard for that team to grow; the catch-all local team is for this. -- Besos, Marga ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] DC15 wrap-up blog post
also sprach martin f krafft madd...@debconf.org [2015-08-29 09:47 +0200]: https://titanpad.com/dc15-wrapup-blogpost It's pretty close to done. Please have a look if you care. I will push this tomorrow (Sunday) morning, if that's alright. -- .''`. 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
[Debconf-team] [content] Adhoc sessions feedback
Hi, This is the first of a series of threads about making the content team more public, documenting things that were done and things that can be improved. This year we did an unconference-like experiment regarding the adhoc sessions, setting two flipcharts near the front desk that listed the slots available to be used for adhoc sessions, one flipchart for the current day and one for the next day. People could simply request a slot by writing down the title of the session in an available slot. Every couple of hours, either Michael or I loaded this info into summit so the event was visible in the online schedule. Pros: - It was very easy for attendees to schedule a new adhoc, and after the first day it was used extensively. - Lots of adhoc meetings were schedule and people were able to know about them both through the flipchart and the online schedule. Cons: - The online schedule wasn't immediate, but best effort based, that was mostly ok, but giggity and the unofficial mobile page wouldn't know about the changes till much later. - It was hard to move a slot, and slots with empty sticky notes on top were not reused. - No drafter information in the unconference flipcharts. - No distinction in the online schedule between adhocs and the official schedule. Feedback heard: - Thanks for making it human friendly. - Much better than last year. - The wiki includes the request to have more time available for adhocs, also popularity vote. Things to improve: From the conference software part it would be better if it had an official mobile page, a clear distinction of the official schedule and the adhoc sessions, and a usable scheduling admin interface. The main issues with summit were the agenda item edition (an agenda item is what binds room, time and event): the event needs to be selected from a randomly sorted select box with all the events from dc14 and dc15, and the time that it takes to load a single event (approx 1 minute!). The official schedule was printed in A4 size, what made it much harder to read from afar than the flipcharts. Something larger would have been nice. We could have used a whiteboard, or a blackboard and chalk (i.e. something that allowed erasing and moving in a better way). More feedback wanted! + What do you think? What needs to be improved? + Should we keep the unconference style adhoc scheduling? Happy hacking, -- pi seconds is a nanocentury -- Tom Duff Saludos /\/\ /\ `/ signature.asc Description: Digital signature ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] [content] Adhoc sessions feedback
martin f krafft madd...@debconf.org writes: Personally, I never used the online schedule much, as I'd learn of ad-hoc events from the mailing list and then just added them to my own calendar. fwiw, I relied a lot on the online schedule, and really appreciated the effort Maxy and Michael put into keeping it up to date. ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] [content] Adhoc sessions feedback
On Sat, Aug 29, 2015 at 03:52:29PM -0300, David Bremner wrote: martin f krafft madd...@debconf.org writes: Personally, I never used the online schedule much, as I'd learn of ad-hoc events from the mailing list and then just added them to my own calendar. fwiw, I relied a lot on the online schedule, and really appreciated the effort Maxy and Michael put into keeping it up to date. Maxy really did around 95% of that work I think, so all credit to him. Michael ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] Getting the DC15 final report done (sprint: 2015-08-31 1900 UTC)
Hi, As a general remark, I think the debconf-data/reports git repo should be split up by year, cause it's really big. So best do that before lots of works starts (in case we use git at all). I wanted to quickly check out what the section layout was for the DC14 report, and it took ages to clone. In related news, I started a skeleton DC15 report during DebCamp and uli Scholler said he would help with typesetting again. On the other hand, I heard from the DC16 camp that they might try scribus this time. On Sat, Aug 29, 2015 at 11:07:06PM +0200, martin f krafft wrote: tl;dr: We'll convene on IRC for a final report sprint on Monday, 31 August, 1900 UTC. I'm on the road then. One idea that's been floating around is to severely reduce the length of the report. Last year's report was almost 50 pages,¹ and only very few people will read that. Most sponsors probably don't, as they mostly care about the highlights of the conference, the numbers and finances, topped with a bit of executive summary (e.g. by the DPL) and maybe some more interesting stuff (e.g. statistics) in the appendix. Agreed. ¹) http://media.debconf.org/dc14/report/DebConf14_final_report.en.pdf On the other hand, it'd be an oversight if we didn't document also the topics we consider integral to our conference, e.g. the cheesewine party, or the day trip, etc.. The final reports are very useful for people joining our team for gaining a basic understanding of what we're doing. Bernelle of DC16 fame suggested to write it all on the wiki, at first, and then we can move stuff to TeX later. This approach enables both: we can create a condensed PDF for sponsors and interested attendees, but we also keep track of everything for later perusal on the wiki. Sounds good. My thoughts: 1. Fold the DPL section as an extensive quote into the introduction/executive summary which also includes the `welcome' and `purpose' sections. 2. Fold `daytrip', `confdinner', `cheeseandwine' and `freetime' into one highly condensed `activities' or so section. 3. Fold `venue' and `food' into one and keep that around, mostly because the venue was really great and I don't want reader who weren't there WTF at 'hostel'. 4. Have lots of quotes from (i) sponsors (might be most difficult), (ii) invited/features speakers (I can reach out to them) and (iii) venue staff. 5. I think we should keep the `credits' section. We obviously have to keep the `sponsors' sections 6. I'd prefer to have a short `talks' section, mostly to highlight the invited/featured speakers. 7. Drop `video' (to be mentioned in the summary of course), `network' (the uplink upgrade can be mentioned as well) and `registration' sections from the PDF version. Michael ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] Getting the DC15 final report done (sprint: 2015-08-31 1900 UTC)
HI, On Sat, Aug 29, 2015 at 11:40 PM, Michael Banck mba...@debian.org wrote: In related news, I started a skeleton DC15 report during DebCamp and uli Scholler said he would help with typesetting again. On the other hand, I heard from the DC16 camp that they might try scribus this time. I did scribus for DC8 and would be happy to do it for DC15 as well. I believe it looks much much nicer. I do think that it's DC15's report and it's DC15's responsibility to get it out, though. I know this is not how it's been for the past years, but I think that the right thing to do is that the team that put out the conference is the one that puts out the Final Report. -- Besos, Marga ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] Patch to DebConf orgateam structure
Hey All, I know from experience, not just with DebConf but with other conferences and volunteer efforts as well, that Marga's points are very pertinent and paying attention to them will make the job much sweeter for the organizers. However, I also feel the vibe behind the Capetowners move to merge the teams, and I remember at least once in NY, when my experience with DebConf was less, having been told something that made me feel unwelcome in global team. Since I find both positions valid and valuable, I propose some sort of synthesis. Maybe a subgroup of the unified global/local team. Also, a clear policy/roadmap for new or local volunteers to join the organization, one which both makes them feel welcome and lets them go only as deep as they feel comfortable, and maybe also some sort of mailing list and/or irc channel special for these volunteers which could be gatewayed/bridged into the standard ones. These are just some ideas off the top of my head, but as I said before, I feel there would be sizeable benefits to be gained from uniting both positions. Cheers! Jergas On Saturday, 29 August 2015, Margarita Manterola margamanter...@gmail.com wrote: Hi, Thanks for the reply. Having read this, I think that the problem lies at what each of us identifies as local team, we are clearly thinking of different things. I wish we could have had this discussion at DebConf. When I say that there should be a local team, it does not mean that members of the local team cannot participate in the global team. Of course, each and everyone of the members of DC16 organization that were present at DC15 (or previous DebConfs, but I think all of them were at DC15) are -in my vision- both part of the local and the global team. When I advocate for the local team it's not for these people, but for the volunteers that will show up along the way. For those volunteers, joining debconf-team is traumatic. There's too many flamewars, too many things going on at the same time, and they have no idea how to fit into the already existing structures, they just want to help. I've heard this comment many times in the past, and even this year, from people that had been part of Debian for a long time, but had no idea how flamewary debconf-team was. We need those volunteers, we need to be able to delegate stuff towards them, otherwise the DC16 organizing team has too big of a burden. But asking those volunteers to join debconf-team, follow the tons of discussions, follow the IRC meeting on #debconf-team, etc, has been proven to be too much. They just don't, which makes it much harder to integrate them so there's a high chance that you'll lose them. Of course, if any new recruits that join that local team feel like they want to integrate into the global structure they are totally welcome to join. It's not like being part of the local team precludes taking part in content, fundraising, or any other teams. It's just that it's not a pre-requisite to understand and fit into the structure in order to volunteer for working towards DC16. In my experience, the group of local volunteers will form whether you want it or not. This year we operated under the there is no local team rule, and we still had plenty of people that helped and showed up only because it was in Germany. Some of them went away because they didn't feel like they fit into the structure, and plenty of them stayed even though they were not part of any of the official teams. The point is that this local team existed even if it was not allowed to exist according to the structure. This will happen for DC16 as well. There will be Southafricans that will join the team and want to help. The easier you make it for them to *belong*, the more motivation and energy they will have to work on DC16. On Sat, Aug 29, 2015 at 1:52 AM, Allison Randal alli...@lohutok.net wrote: - Another supporting reason was to clearly define who would be working on social activities like the day trip and evening events, but there's no reason that has to be exclusively local people, so it made more sense to just create a Social Activities team. We had a similar conversation around budget and facilities, where it makes more sense to combine people with varying levels of experience and proximity, rather than artificially segmenting the work. I don't object to these new teams. I just want to point out that the intention of the original team structure was to ensure that people stayed on the teams through the years. These teams will have an extremely high turn-over (i.e. most members will only be members for one DebConf). In my original proposal, only the local team would have such a high turnover, but I'm fine with accepting that there's a bunch of teams in the same situation. These teams do not solve the problem described above, local volunteers still need to figure out which team out of Facilities, Social Activities or Finances they fit in, and
[Debconf-team] Getting the DC15 final report done (sprint: 2015-08-31 1900 UTC)
tl;dr: We'll convene on IRC for a final report sprint on Monday, 31 August, 1900 UTC. With DebConf15 over, it's now time to get the final report out of the door. This report is not only required for DC16 fundraising, it's also a valuable asset for DebConf future. And it can actually be quite fun and rewarding to write about the success we made happen altogether. One idea that's been floating around is to severely reduce the length of the report. Last year's report was almost 50 pages,¹ and only very few people will read that. Most sponsors probably don't, as they mostly care about the highlights of the conference, the numbers and finances, topped with a bit of executive summary (e.g. by the DPL) and maybe some more interesting stuff (e.g. statistics) in the appendix. ¹) http://media.debconf.org/dc14/report/DebConf14_final_report.en.pdf On the other hand, it'd be an oversight if we didn't document also the topics we consider integral to our conference, e.g. the cheesewine party, or the day trip, etc.. The final reports are very useful for people joining our team for gaining a basic understanding of what we're doing. Bernelle of DC16 fame suggested to write it all on the wiki, at first, and then we can move stuff to TeX later. This approach enables both: we can create a condensed PDF for sponsors and interested attendees, but we also keep track of everything for later perusal on the wiki. To kick off the effort, I would like to invite you to join us at regular DC15 meeting times, next Monday, 2015-08-31, at 1900 UTC in #debconf-team. I bet everyone can write an article or a half in an hour and that'll take us a long way towards completion of the final report, the earlier we are done with it, the better. Hope to see you there! -- .''`. 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
Re: [Debconf-team] [content] Adhoc sessions feedback
also sprach Maximiliano Curia m...@debian.org [2015-08-29 20:06 +0200]: This is the first of a series of threads about making the content team more public, documenting things that were done and things that can be improved. \o/ From the conference software part it would be better if it had an official mobile page, a clear distinction of the official schedule and the adhoc sessions, and a usable scheduling admin interface. Why do we want a distinction between ad-hoc stuff and the official schedule? More feedback wanted! + What do you think? What needs to be improved? I had the impression that it really worked a lot better than last year. The idea of using a whiteboard or chalkboard seems to make a lot of sense. Personally, I never used the online schedule much, as I'd learn of ad-hoc events from the mailing list and then just added them to my own calendar. + Should we keep the unconference style adhoc scheduling? I'd say: yes, definitely. I think it's a core part of our conference. If we didn't coordinate this, people would find ways anyway. I've even heard and entertained thoughts about extending it and *reducing* the number of officially scheduled events to two tracks (e.g. technical and political/social/philosophical), concentrating on events we know will draw a large audience, and making sure that there is enough space for everyone else, including the possibility to video-stream, etc. -- .''`. 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
Re: [Debconf-team] Patch to DebConf orgateam structure
On 08/29/2015 03:01 AM, Margarita Manterola wrote: When I advocate for the local team it's not for these people, but for the volunteers that will show up along the way. For those volunteers, joining debconf-team is traumatic. There's too many flamewars, too many things going on at the same time, and they have no idea how to fit into the already existing structures, they just want to help. One thing we need to work on is reducing those flamewars. They're not helpful to anyone. We absolutely need to improve communication and collaboration in the whole team. Remember, long-term team members aren't immune to being driven away by an unhealthy environment. We need those volunteers, we need to be able to delegate stuff towards them, otherwise the DC16 organizing team has too big of a burden. But asking those volunteers to join debconf-team, follow the tons of discussions, follow the IRC meeting on #debconf-team, etc, has been proven to be too much. They just don't, which makes it much harder to integrate them so there's a high chance that you'll lose them. Of course, if any new recruits that join that local team feel like they want to integrate into the global structure they are totally welcome to join. It's not like being part of the local team precludes taking part in content, fundraising, or any other teams. It's just that it's not a pre-requisite to understand and fit into the structure in order to volunteer for working towards DC16. That point was mentioned too. But again, all that requires is for local members of the DebConf team to make local volunteers feel welcome. Defining a local team doesn't help with that. Allison ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] Patch to DebConf orgateam structure
On Sat, Aug 29, 2015 at 12:14:01PM -0700, Allison Randal wrote: On 08/29/2015 03:01 AM, Margarita Manterola wrote: When I advocate for the local team it's not for these people, but for the volunteers that will show up along the way. For those volunteers, joining debconf-team is traumatic. There's too many flamewars, too many things going on at the same time, and they have no idea how to fit into the already existing structures, they just want to help. One thing we need to work on is reducing those flamewars. They're not helpful to anyone. We absolutely need to improve communication and collaboration in the whole team. Remember, long-term team members aren't immune to being driven away by an unhealthy environment. I've been wanting to say much the same. The unhealthy environment is one of the main reasons I stopped participating for many months earlier this year. I'm sure I wasn't the only non-newcomer to walk away. I know that wasn't a helpful reaction. At the same time I felt that venting my frustrations and growing rage wouldn't have been helpful either. Also, non-local newcomers can be and probably have been put off by the disfunctions in the overall team environment. We need those volunteers, we need to be able to delegate stuff towards them, otherwise the DC16 organizing team has too big of a burden. But asking those volunteers to join debconf-team, follow the tons of discussions, follow the IRC meeting on #debconf-team, etc, has been proven to be too much. They just don't, which makes it much harder to integrate them so there's a high chance that you'll lose them. Of course, if any new recruits that join that local team feel like they want to integrate into the global structure they are totally welcome to join. It's not like being part of the local team precludes taking part in content, fundraising, or any other teams. It's just that it's not a pre-requisite to understand and fit into the structure in order to volunteer for working towards DC16. That point was mentioned too. But again, all that requires is for local members of the DebConf team to make local volunteers feel welcome. Defining a local team doesn't help with that. A safe environment to discuss DebConf in a given year's local language is one solid argument I've heard in the past in favor of a local team. I don't recall seeing that mentioned in this thread thus far. I think there have been more than a few years where many local newcomers, and consequently the conference as a whole, benefitted from being able to communicate about the conference in their native language. Perhaps that need can be met by an irc channel and list, without being a formal team. I honestly don't know. Not an issue for dc16, afaik, but should be kept in mind as we are talking about more than just the coming 10 months. -edrz ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
