[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debconf-team] Timeline: Registration, Content



also sprach Bernelle Verster <bernellev@gmail.com> [2015-10-11 13:38 +0200]:
> For (general) website content drafting, would it make sense to put
> it on a wiki and then migrate that content to the website once
> we're ready to load content up? Or is a titanpad good enough on
> a section by section basis? Or how is this generally done?

In the past, the website was made up of XHTML pages stored in Git.
We hope that we'll soon have wafer handling debconf16.debconf.org,
allowing us to write content using e.g. reStructuredText mark-up
(RST):

  http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html

This is a sensible baseline format, as it would even allow us to
generate the XHTML if we wanted, so my suggestion would be to draft
on Titanpad, but write actual articles/content as RST and keep it in
Git.

> For now I'm just fiddling on a titanpad [1] . Where is DC15's CfP?

https://bits.debian.org/2015/03/debconf15-cfp.html

> I don't consider this too urgent, as the brochure had general
> enough information that the sponsor requested (which is what
> prompted me to ask about this). The first registration deadline is
> also an 'Expression of Interest' which may not explicitly require
> this yet...?

Well, there've been disagreements about this in the past.
Traditionally, DebConf has opened registrations and then called for
proposals some time later.

The argument for doing it this way has always been that people first
need to find out whether they're going before putting effort into
writing proposals, and also if we opened earlier, people would still
wait until the last possible moment to submit proposals.

The latter is probably true (so the "last possible moment" should be
chosen wisely), but I (and some others) have a problem with the
former, and if only because it makes things harder for us
organisers.

Also, all other conferences that I know first call for proposals,
then try to publish a preliminary schedule, and *then* try to get
people to register for the conference sporting this schedule.

We don't need to be sales-driven like this, but it's also been
a common criticism for people who have problems getting permission
from their employer to attend a conference before they find out
whether they'll be able to present a project of theirs, and without
knowing the schedule. I.e. many of us do go to DebConf as a matter
of course, but there are also a lot of people who could benefit from
having the schedule available to convince their bosses and determine
the dates they want to take off work.

The current proposal is indeed to replace
registration/reconfirmation with preliminary-interest/registration,
or put differently: you'll be able to create an account in the
conference management system early on, but we won't really be asking
much input from you, so as to not give the impression that you've
then already registered.

In fact, preliminary registration (account creation) only serves
four purposes:

  1. Give us your e-mail address so that we can let you know when
     registration opens (or other important things start, e.g.
     sponsorship applications);

  2. Allow people seeking sponsorship to engage early;

  3. Let people submit event proposals;

  4. Give us an idea of how many people are generally interested.

Long story short, independent of when we terminate each step (which
depends a lot on wafer…), the call for proposals can be sent any
time from now, and it doesn't hurt to have it done earlier than
later. It gives people an incentive to start thinking about
proposals, and it can be resent as many times as we want or need.

It's also not a lot of work, especially if you base it off the DC15
one. And when it's done, then it's done. ;)

-- 
 .''`.   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)


Reply to: