Assuming some effort is put in (both coding and using the feature) I think a better use of time is tags.
which should require a PHD in tagology or something before I continue ;) I have seen tags be done well and less so. I am not sure what the magic is. But I often see other metadata that to me looks like tags with some restrictions that I think is to try to make them good. the pattern is a key:value where the key is mostly meaningless and the value is all anyone cares about. Tracks are bunch of talks with similar subject, that get grouped in space and time. I hope Waffer has support for tags, or if it doesn't, maybe that is a better feature to add instead of track? (and then use tags to manage tracks) I would love to be able to find talks about packing python things. it would be so much easier to find if they are tagged as such. I suspect that considering some sort of tag management will be better effort than limiting it to the track concept. On Sun, Feb 14, 2016 at 3:58 PM, martin f krafft <madd...@debconf.org> wrote: > also sprach Asheesh Laroia <ashe...@asheesh.org> [2016-02-14 09:32 +1300]: > > If people have ideas for tracks, I could possibly be convinced to > > do "own" one such track, which would mean doing the work of > > finding speakers who canA talk interestingly on topics within that > > track. I'd love to hear about people's ideas for tracks. > > It's a great idea to explore, I think. The reason why I questioned > the need for tracks is because I (personally) don't see much of > a value of using tracks only to colour-code the schedule, and if > that were our only use, I'd rather leave out this additional form > field and data point. However, if we are ready to explore "owning" > tracks as you suggest, then adding the functionality is well worth > it. > > Allow me to mention linux.conf.au (LCA) in this context. The > conference runs for only 3 days, but is preceeded by 2 days of > "miniconfs". For the main conference, keynote speakers are > actively sought, the rest is submissions-based. Since the > conference enjoys a very good reputation, the organisers regularly > get flooded with submissions, and they've made it a habit to pass > off rejections to miniconfs, if there is a match. My proposal this > year was passed on to the sysadmin miniconf, for instance. > > Miniconfs on the other hand are similar to the idea of "owned > tracks". There's a chiefly responsible person setting the theme > and drafting up a schedule, inviting speakers and vetting > submissions passed over from the main conference. > > In the past few years, we've provided a list of possible tracks in > the call-for-submissions, as a means to help people to come up with > ideas. This list hasn't really changed, and I am not sure we'll > be able to reap much of a benefit if we keep the entries static as > they are and try to find people to take responsibility for each. > That seems a bit like creating arbitrary subtasks and assigning them > to people, which isn't particularly motivating, if it even works. > > But how about opening this list and calling for track idea > submissions early enough in the cycle, such that people are > motivated to make "their" idea happen, while also bringing fresh > ideas to the conference, continuously? We'd still have to have > a couple of standard tracks, of course… > > Assuming we get a few ideas back, the conference organisers could > then pick some and include them in the call-for-submissions. > Meanwhile, the track owners would also seek for themselves, and when > submissions come in to the content team, they'd refer to the > appropriate track owners. > > It'd mean allocating slabs of space in the schedule and bestowing > responsibility of the scheduling to the owners. It might not work > right away, but long-term, this could take quite the burden off the > content team. > > So Asheesh might have proposed the "Applying Debian values and > techniques to the Web" track, someone else might suggest > a "Packaging with Git" track, and there might be a "Creative > content with Debian" theme, or "Debian for kids", etc.. Add > these to the standard "bits from Debian teams" group of talks, as > well as the "miscellaneous" pool. > > The next year might be all different. > > And we'd be able to advertise a whole lot of content (general > ideas anyway) well before finalising the schedule. > > I am all in favour and I'd be willing to take ownership of a track, > if this is something we think we can still hammer to shape for DC16… > > -- > .''`. 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 > > _______________________________________________ > Debconf-team mailing list > Debconf-team@lists.debconf.org > http://lists.debconf.org/mailman/listinfo/debconf-team > >
_______________________________________________ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
