Re: [Debconf-team] DebConf14 wrap-up blog post
also sprach Paul Wise [2014-09-16 13:16 +0200]: > The Debian publicity team prepared a wrap-up DPN entry about DebConf14. > We would like to publish it on the DebConf blog (Martin Krafft > volunteered to do so) but would like some input from DebConf14 folks > before doing so. Hopefully you are still subscribed to the list :) > > https://anonscm.debian.org/viewvc/publicity/dpn/en/2014/13/index.wml?view=markup Any objections? You may even write in if you think this is good, hint hint! Let's get this out tomorrow, shall we? -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems "alle menschen zerfallen, wie zu allen zeiten so auch jetzt noch, in sklaven und freie; denn wer von seinem tag nicht zwei drittel für sich hat, ist ein sklave, er sei übrigens wer er wolle: staatsmann, kaufmann, beamter, gelehrter." - friedrich nietzsche 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] Report from the talks team
also sprach Ana Guerrero Lopez [2014-09-16 22:19 +0200]: > * We must find a way to make submitters to make better talks > descriptions. Bad or incomplete talks description made to waste > a lot of time to both the talks team and attendees. Yeah, I can see this very well. We should make sure that people put at least as much time into making a submission as it takes us to evaluate it. Some additional ideas to make our job easier might include: - Ask participants to provide links to previous events or videos, allowing us to evaluate the quality of the speaker. Note that I am not talking about witty audience magnets only, and I have seen fantastic(ally prepared) speakers who presented in their !first language and didn't have perfect slides. - We have not really been collecting feedback on speakers, but starting this for DC15 would probably make things easier in the future. - If we decide to introduce other talks formats, then we should not be afraid to suggest to people that their event should be resubmitted for a different format, e.g. a shorter slot, or a workshop etc. > * Publishing the list of accepted talks ahead and taking the time > to schedule seems to be a good idea. There are plenty of people > making travel plans at the last minute and allows last minute > additions. It'll also attract people to the conference. > * To take better advantage of Summit's interface, probably we > should provide the list of talks still without scheduling, and > wait for people to fill in their talk interests and use this data > for better scheduling. This will be hard to present in a tangible way. But I could imagine having a page for the different tracks, and listing the talks for each track. Yes, having attendee "stars" in summit might well allow us to semi-automate the scheduling, at least let an algorithm do the first version for fine-tuning by hand. > * Doing the talks selection off-line without having to rely in the > web interface but still with all the data about the talk, seemed > to work fine. But we might want to study betters way to implement > this that a big CSV dump. For bursaries, we had a simple interface allowing us to vote on each participant with between -3 and +3 points. This would be trivial to do for events too, I guess. The actual scheduling would be best done with drag-n-drop, I feel, but someone will need to implement this on top of Summit. No idea how hard this is going to be, but it doesn't sound easy. > * We don't know if accepting some talks ahead was good for > encouraging events submission or not, but it created some buzz > around the conference. It also makes some of us wonder if there > was a skew of the criteria used to select the talks accepted > before the deadline and if this was a sensible bias or not. I think it was great and the buzz is good. I do not understand your second sentence. Could you please elaborate? > * When scheduling tracks we need to know what's the best temporal > organization: > - the "intensive day" approach > - the "repeated theme" approach through the full conference > - or just making sure the associated talks do not run concurrently. > Having a designated coordinator for any given track can help us > make the relevant decision for future conferences. I think the intensive day approach is going to be too intense, and we also risk conflicting between tracks in general, i.e. some people might want to go to "Debian Culture" and "Cloud Computing", which just happen to be on the same day, so multiple conflicts are preprogrammed that way. A track coordinator is a good idea and could even help with talk selection up front! But in general, I think it might be better to just schedule chaotically, ideally based on attendee feedback to minimise conflicts for those who participate. > * Some of us wondered if the tracks should not have been presented > for people to choose from during event submission, or if they > were, they need to be clearly marked as "optional" or "any" -- > when we added tracks partway through the conference, we should > have been able to try to group the tracks later. My personal thought: it was a nuisance to figure out which track is best, and none of my submissions really fit anywhere. So I think we have to chose either to have a pre-defined set of tracks (with a coordinator knowledgeable in the field) for each, and then be strict about it… (this can help guide people's decisions on what to submit) … or just accept it all and see if we can create any tracks after selecting the talks we want. We do not *need* the concept of tracks at all. > Another possibility would have been encouraging people to type in > 3 or 4 keywords about their proposal to make it possible to have > a tag cloud that would "bubble up" ideas for possible new tracks. Nice idea! -- .''`. martin f. krafft @martinkrafft : :' : DebConf orga team `. `'` `- DebConf14: Portland, OR, USA: http://debconf1
Re: [Debconf-team] HTTPS certificate cannot be verified warning on your site
also sprach Joe Alderson [2014-08-27 17:10 +0200]: > According to my browser, your HTTPS certificate "cannot be > verified up to a trusted certification authority". This pops up > a big warning message the first time someone tries to visit > certain pages of your site, so just thought I'd let you know, as > we're currently linking to this page in particular: Thank you, Joe, for bringing this to our attention. We are actually aware of this problem and we are hoping to find a solution soon. Kind regards, -- .''`. martin f. krafft @martinkrafft : :' : DebConf orga team `. `'` `- DebConf14: Portland, OR, USA: http://debconf14.debconf.org DebConf15: Heidelberg, Germany: http://debconf15.debconf.org 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] Report from the talks team
On Thu, Sep 18, 2014 at 11:13:30AM +0200, martin f krafft wrote: > also sprach Ana Guerrero Lopez [2014-09-16 22:19 +0200]: > For bursaries, we had a simple interface allowing us to vote on each > participant with between -3 and +3 points. This would be trivial to > do for events too, I guess. > > The actual scheduling would be best done with drag-n-drop, I feel, > but someone will need to implement this on top of Summit. No idea > how hard this is going to be, but it doesn't sound easy. Summit has a javascript drag-n-drop thing[0]. ///display?edit is available to those with scheduler permissions. It is a one-day-at-a-time scheduling interface. I played with it briefly and found it buggy and glitchy in my local summit instance. I don't know if anyone tried it on the live site. If that kind of thing is wanted, it already exists. Might just need some small(?) tweaking. Personally, I would find it cumbersome even if it can be made to work properly. But, I am not a scheduler and generally avoid mice as much as I can, so maybe it would be fine for those doing this work. -edrz [0] In debconf-data/summit.git on alioth: view: summit/schedule/views.py_process_date_view() json: summit/schedule/render.pyjs_data() template: summit/schedule/templates/schedule/schedule.html javascript: summit/media/schedule/schedule.js summit/media/ajax.js ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
Re: [Debconf-team] Report from the talks team
Several diverging comments below: On Thu, Sep 18, 2014 at 11:13:30AM +0200, martin f krafft wrote: >also sprach Ana Guerrero Lopez [2014-09-16 22:19 +0200]: > >> * Publishing the list of accepted talks ahead and taking the time >> to schedule seems to be a good idea. There are plenty of people >> making travel plans at the last minute and allows last minute >> additions. > >It'll also attract people to the conference. Is there that much of an effect? Maybe a small number of people. I'd expect the vast majority of folks coming to DebConf will come regardless of the explicit talks schedule. Some may change their travel dates to accommodate specific talks, though - I've seen that happen. So +1 to Ana here. >> * Some of us wondered if the tracks should not have been presented >> for people to choose from during event submission, or if they >> were, they need to be clearly marked as "optional" or "any" -- >> when we added tracks partway through the conference, we should >> have been able to try to group the tracks later. > >My personal thought: it was a nuisance to figure out which track is >best, and none of my submissions really fit anywhere. > >So I think we have to chose either to have a pre-defined set of >tracks (with a coordinator knowledgeable in the field) for each, >and then be strict about it… (this can help guide people's decisions >on what to submit) > >… or just accept it all and see if we can create any tracks after >selecting the talks we want. > >We do not *need* the concept of tracks at all. If tracks are considered useful, try and define them as early as possible and get coordinators up-front. >> Another possibility would have been encouraging people to type in >> 3 or 4 keywords about their proposal to make it possible to have >> a tag cloud that would "bubble up" ideas for possible new tracks. > >Nice idea! Definitely - I was going to suggest exactly the same thing as a way round the "my talk doesn't fit any of the tracks" problem. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... ___ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
