> > > We'd like to use Pentabarf for our entire registration > system. Since we > > had to copy everyone from our main reg system into > Penatabarf so they > > could use the self-scheduling system (which was a REALLY BIG DEAL at > > the convention, everyone LOVED it) we decided next year to > instead just > > enter everyone into pentabarf instead. One problem is that > the current > > system needs email addresses to be unique, there is just no > way this can > > be done in a live conference, attendees often share the > same email address. > > It > > would be nice if there were some other niceties for dealing > with conference > > attendees. > > I plan to separate the visitor system accounts from pentabarf > accounts. This > would also remove the necessity for unique email addresses > and you don't > clutter your person table with participant entries.
Most of our speakers attend other events, we gave them accounts in the visitor system and from that they were able to get a fully merged list of events they were speaking in and events the were in the audience for. It also let them add events they wanted to attend and have the conflict system warn them if those events conflict with their speaking engagements. Would this still be possible if you separated the two tables? > > Some kind of mechanism for "user defined" fields. As an > example, we rated > > all of our talks by skill/expertise, ie, > beginner/intermediate/expert. > > There > > was no way to encode this into the event (we ended up > putting it in the > > description). It would be nice if there was a flexible, > easy to use way to > > tag events with properties or fields specific to one > convention. Also, > > applying the same > > logic to rooms, it would have been nice to be able to flag > some rooms with > > properties important to us, say, like if the room had a PA > system, or > > electric > > outlets, number of chairs, etc. What we did is prefix all > the room numbers > > with codes for > > properties in the scheduling phase, then stripped all those > off later. The > > design > > should make it easier for a convention to customize what is > stored about a > > person/event/room. > > Can you give some more examples. What other fields did you miss. > For stuff like PA, chairs, ... it is planned to have a > subsystem for resource > management. But it's unclear whether this will make it into 0.3. One thing that would have been nice is a property of what hours we had the room (or it was available) each day. We ended up creating non-public sentinel events at the end of each rooms' day to try and mark when we needed to shut them down overnight (it varied for different rooms). > > The Day 1 2 3 references weren't very user-friendly, I hack > in a little bit > > of ruby to translate them into proper day names (in a very > non-portable > > way), it > > would be nice if this were actually in the code. > > > > Our schedule is still browsable here... > > http://www.gamestorm.org/schedule/day_1.en.html > > we made a bunch of minor localization changes of no general > interest, but > > some of them > > I'm sure other people would be interested in. For example, > we wanted to be > > able to look > > up a person and see what there public schedule was in an > "info box" sorted > > by time > > http://www.gamestorm.org/schedule/speakers/43.en.html > > and a few other small changes along the same lines. I've > been meaning to > > diff our tree > > against the original and make a commented list of changes, > maybe I'll do > > that soon. > > I really like the changes you made to the html export > escpecially the events > by track stuff and the info box at the speaker page. I would > love to get a > diff of your modifications. Yes, although I'm not sure I can reliably identify which version I should be diffing it against anymore, it's been a few months since I looked at it. In any case I can always tar up the whole tree (and give you a copy of our database if you'd like to play with it live). The events-by-track stuff really demonstrated the ease of extending the system, it's only about 15 lines of extra code, or at least it would have been. It was supposed to be a mod to "events" to also accept a track parameter, but rails was acting in a way I didn't understand and I ended up just copying events to a new events-by-track method and then adding those 15 lines instead of learning what I was doing wrong on the rails end. If you get some free time I could create an account for you on the visitor system if you want to see what it looks like live. I added a non-grid view also. It would also let you see what I meant by having the speaker and visitor schedules being fully merged. > > > > > Finer-grained permission controls. It would have been VERY > nice to be able > > to delegate > > control of rooms to certain departments so they could only > schedule events > > into those > > rooms. Also, the ability to tag submissions with which > department could > > then be > > in charge of scheduling it. > > The permission system will be changed a lot for 0.3. I plan > to implement > conference-based permissions but it's not yet clear how > exactly the permission > handling for 0.3 will be. I think per room permissions really > make sense too. > If you have further ideas/suggestions for the permission > controls please tell > me about it. The coordinator model worked well for the actual event, but we'd like to have similar ownership of rooms (you need to be the coordinator of a room to be able to assign an event to it) and of people (you'd need to be a person's coordinator to be able to add them to an event). _______________________________________________ pentabarf mailing list pentabarf@mail.skyhub.de https://mail.skyhub.de/cgi-bin/mailman/listinfo/pentabarf
