Re: [Debconf-team] Registration plan / pentabarf changes
Hi,
As you know, I was the only silly guy to say "I'll work with
Penta". Worst part: I have already done it, I know what it feels
like. Anyway - I didn't even want to open your mail earlier on, until
I had time to get a bit of Penta-grip on my hands.
So, today I pushed the first bit of changes (verrry minor and only on
the views). So, I'll reorder your mail to be able to be more punctual
on my reply:
> Pentabarf changes
> =================
Removing and hiding is thankfully very easy ;-)
> remove these fields:
> - disabilities (we'll have people mail registration@ diectly)
> - computer
> - OK being photographed (unless someone will actually do something
> with it)
>
> hide these fields (the proper way -- these fields get activated later
> on):
> - reconfirm attendance
> - day trip
> - maybe 'assassins' too, until someone agrees to run it
Done. The fields are only mentioned in the view - I'd also like to
drop them from the DB schema, but I'd rather ask somebody more
experienced in this regard running with multi-year databases: I don't
want to kill preexisting data.
The daytrip and assassins fields were commented on the source, and the
"reconfirm attendance" is conditionally shown once the relevant option
is set on the specific conference.
Now, again, as we are dealing with previous years as well: Whatever I
do will affect how older DebConfs' data is displayed. How much should
I care about it? i.e. once my changes are pulled into the live site,
displayed information for past DebConfs won't include the fields
mentioned here. Does it matter? What should be the guideline for not
doing a given change (or introducing it as a per-conference
conditional, as adding «if @conference.f_reconfirmation_enabled» now)?
> - address except country (do we need this for anything here?)
I would leave this one. It might not be too useful, but it can. I am
thinking about examples involving visa requests or shipments - It's
much better to have too much information than too little.
> - "special transport requirements" - we'll have them mail
> registration@ directly
Oh! Found it... Ok, removing it as well (as a separate commit). Same
comments as the previous section...
Now, before going on to the registration options: How should I push
the changes? Right now, I pushed to the git tree, but have no way even
to check it on cletus (as I have no privileges to touch
/opt/penta/www). I suppose that for pushing a set of commits into
skinner I'll have to bug the admins, but what about cletus? It
involves not only pushing the changes, but restarting the app server,
and possibly pushing some changes to the DB structure eventually.
> (...)
> The key thing here is there is no more "professional" category, we
> have these people book a room at the hotel directly, instead of us
> being a broker.
>
> I sort of prefer option A, but it can go either way.
>(...)
> Registration option A
> ---------------------
>
> change these fields (XXX how do we want to do this?):
> - Category:
> * Corporate registration (€XXX)
> * Registration only (sponsored) [internal: 'unsponsored']
> * Registration + accommodation + food (sponsored) [internal: 'sponsored']
>
> - accommodation: question ONLY for sponsored people:
> * Reserve sponsored accommodation for me (ONLY display for Sponsored
> status, but needs to be default for that)
> * I will arrange my own accommodation
>
> - food options as for dc10
>
>
> Registration option B
> ---------------------
>
> - Category:
> * Corporate registration (€XXX)
> * Registration (sponsored)
>
> - accommodation: question ONLY for sponsored people:
> * I will arrange my own accommodation (default option)
> * Reserve sponsored accommodation for me (ONLY display for Sponsored
> status)
>
> - food options as for dc10
Why do you prefer A? I think B would be clearer.
> Registration text for website
> =============================
Oh, and as soon as the text is ready, I'll push it in as well.
Greetings,
Reply to: