I added the worker item to the performer, that was fine.

But I started thinking through the logic for act accept with the idea that

Show is an Event (to EventItem to scheduler.Event) Event has resources allocated, including a Performer (which is a Persona, Combo or Troupe) The performer is someone who submitted 1 or MANY acts.

That is where the chaos comes in.

We already have performers in the system who have submitted (legitimately -- not issue #150) more than one act to us:

Maggie McMuffin - Black Swan, Porn Theater - both submitted
Cherie Nuit - Dang Tourist! (submitted), Bait (not submitted)
Serendipity Love - Candy Girl Did a Bad Thing, Killer Queen - both submitted
Nissa Citrine - 1 submitted, 1 not submitted
Penny Wren - 1 submitted, 1 not
Deliliah Spring - both submitted
Mistress Leona Star - 1 submitted, 1 not

We can generally assume that accepting both acts is very rare. Accepting 2 acts from 1 performer for 1 show is damn near impossible. BUT - we have in the past accepted 2 great acts for 2 shows.

But - this poses the problem:

we accept 2 acts for 2 shows - which act goes with which show? This matters for Act tech info! The tech info builds off the starting act, we need the right producer and tech director and stage manager to get the right act!

If we absolutely, 100% guarantee that we will NEVER do this without some sort of acceptable painful workaround (make a copy of the performer), then we can say that we know what act is in the show because:

the performer is cast in the show (event -> resource allocation -> performer
and THIS is the act that is accepted

I'm worried, though, because I could see this coming up for special guests, too, if we ask them at some point to do 2 acts... say Rhinestone Review and Main Event not in competition.

I'm not actually sure what you're asking me...

From my POV it's the /act/ that gets assigned to a show and sort of drags the performer along with it, so I don't see the chaos if we accept two acts from the same performer in two different shows (as rare a case as that may be).

At least once a year for the past two years we've had a situation where a performer is both a solo performer and in a group act in the same show. The Troupe identity may prevent this case from being a total clusterfuck, in that if I accept both "Betty Blaize" and "The Boston Babydolls" to the same show, we treat them as two different resources, right?

There are also situations like where someone might be in the opening act (like we did last year) and also in The Main Event (either compete or non-compete). Although, the work around for that situation is to make the opening act a volunteer event and not submit it through the act system.

I cannot guarantee I will /never/ accept two acts from the same person.
I can't even guarantee I won't accept two acts from the same person for the same show... although (except as discussed above) it would be a pretty edge case.

I agree with Scratch, the Act is what should be linked to the show. That's how it was in my original design, but for some reason we got away from that.

Performers are not the right linking point, though it would be convenient from a scheduler point of view. The question is how to make the right way work correctly - I'll have to think about how that works. (clearly we don't want to just slap a second allocation onto the show to represent the person

that way lies madness)

I cannot guarantee I will /never/ accept two acts from the same person.

It would be insane to build a scheduler that wouldn't allow you to accept two acts from the same person. You should be able to schedule a whole show of one person if that's what you want to do.

On Fri, Oct 24, 2014 at 11:40 PM, Scratch notifications@github.com wrote:

I'm not actually sure what you're asking me...

From my POV it's the /act/ that gets assigned to a show and sort of drags the performer along with it, so I don't see the chaos if we accept two acts from the same performer in two different shows (as rare a case as that may be).

At least once a year for the past two years we've had a situation where a performer is both a solo performer and in a group act in the same show. The Troupe identity may prevent this case from being a total clusterfuck, in that if I accept both "Betty Blaize" and "The Boston Babydolls" to the same show, we treat them as two different resources, right?

There are also situations like where someone might be in the opening act (like we did last year) and also in The Main Event (either compete or non-compete). Although, the work around for that situation is to make the opening act a volunteer event and not submit it through the act system.

I cannot guarantee I will /never/ accept two acts from the same person. I can't even guarantee I won't accept two acts from the same person for the same show... although (except as discussed above) it would be a pretty edge case.

— Reply to this email directly or view it on GitHub https://github.com/bethlakshmi/GBE2/issues/151#issuecomment-60470385.

OK, now I'm just beyond confused, because I agree with you both BUT that is NOT what I heard on the conference call on Thursday. In fact, I have NOT pulled Jon's original logic that linked Show to Act because it just felt awful and I already had nicely working business logic for it.

On Thursday, we all agreed that a Performer should be a WorkerItem which is how we make someone (or their persona) schedulable. I was under the impression from us all talking that we wanted this because Jon didn't want two ways of doing the same thing - booking people for stuff. I assumed that that meant that the thing we were trying to avoid was:

Way # 1 (the old way) - an Event can be a Show, a Show includes Acts, Acts have Performers, Performers are connected to Profiles/Users (that is 1:1 so it's the same thing) - so if you want to see what performers are in what shows you can go to the show, ask for acts, ask for performers, get the users who are part of that pack of performers (persona = 1 user, troupe & combo = +1 user)

Way #2 (the new way) - we have a way to schedule the actual people for events. We have a scheduled Event, it has is allocated the resources that include workers, workers can be profiles (the actual human user) or the performer (that's what I checked in last night), so that a performer (persona, troupe, combo) can be scheduled for an event.

Does it make sense to both of you that it's OK to have BOTH of these ways? I actually am OK with that... but it adds complexity whenever an act & performer are assigned and unassigned from shows.

When that happens both paths through the data must be updated.

Example:

Assign act to show:

the show object is updated with a new act (that corresponds to WAY # 1 above)
if the performer was previously NOT scheduled for this show - all scheduler.event objects for this show are given a new resource allocation for the performer for this act so that the performers' schedules are booked properly. (WAY # 2)

Remove act from show:

the show object is updated to remove the act from the show (WAY # 1)
the scheduler.event objects for this show are updated, and if this is the only act that this performer is in for this show, the resource allocation assigned to this performer to this show is removed, which means the perfomer no longer shows up as booked for this show. (WAY # 2)

I'm trying to be as precise as I can here about how the logic works in the code, without going through every single data related connection between the show and the act and the performer - so that I hope that both Scratch and Jon can follow me...

I'm actually OK with having 2 ways to book people and their acts into shows - I think it makes traversal of all the logic easier in a number of other places. (showing performer's their schedules, showing the bios of performers who are in shows, linking act tech info to shows, linking opportunities for rehearsal times to shows) - it would be easy enough to write the logic for this on the model level that lets an Act be smart about it self - it could have the power "book me for a show" where "me" is the act and then do the right thing if given a show id. And similarly "unbook me for a show" and we could let the act take it from there. Then the logic is in once, nice happy place and we can tap it for any thread...

So if I misunderstood what everyone else wanted on the conference call - great! That's awesome because it means the model as is is great, and doesn't need messing with, I just have some business logic changes to make to act approval.

In complete honesty, as soon as you and Jon start using terms like "WorkerItem" I stop listening because I know longer know what you're talking about.

I'm in favor of more control and less chaos. I'm in favor of solutions that make it easy to undo stupid user mistakes -- or make it harder for the users to make stupid mistakes in the first place.

But I'll leave the specifics of the code to you guys because I don't have the tools to evaluate the different options.

Sorry if that's not as helpful as it could be...

The Great Burlesque Exposition #9 February 20-22, 2015 www.Burlesque-Expo.com

BurlExpo9

On Oct 25, 2014, at 12:28 PM, bethlakshmi notifications@github.com wrote:

OK, now I'm just beyond confused, because I agree with you both BUT that is NOT what I heard on the conference call on Thursday. In fact, I have NOT pulled Jon's original logic that linked Show to Act because it just felt awful and I already had nicely working business logic for it.

On Thursday, we all agreed that a Performer should be a WorkerItem which is how we make someone (or their persona) schedulable. I was under the impression from us all talking that we wanted this because Jon didn't want two ways of doing the same thing - booking people for stuff. I assumed that that meant that the thing we were trying to avoid was:

Way # 1 (the old way) - an Event can be a Show, a Show includes Acts, Acts have Performers, Performers are connected to Profiles/Users (that is 1:1 so it's the same thing) - so if you want to see what performers are in what shows you can go to the show, ask for acts, ask for performers, get the users who are part of that pack of performers (persona = 1 user, troupe & combo = +1 user)

Way #2 (the new way) - we have a way to schedule the actual people for events. We have a scheduled Event, it has is allocated the resources that include workers, workers can be profiles (the actual human user) or the performer (that's what I checked in last night), so that a performer (persona, troupe, combo) can be scheduled for an event.

Does it make sense to both of you that it's OK to have BOTH of these ways? I actually am OK with that... but it adds complexity whenever an act & performer are assigned and unassigned from shows.

When that happens both paths through the data must be updated.

Example:

Assign act to show:

the show object is updated with a new act (that corresponds to WAY # 1 above) if the performer was previously NOT scheduled for this show - all scheduler.event objects for this show are given a new resource allocation for the performer for this act so that the performers' schedules are booked properly. (WAY # 2) Remove act from show:

the show object is updated to remove the act from the show (WAY # 1) the scheduler.event objects for this show are updated, and if this is the only act that this performer is in for this show, the resource allocation assigned to this performer to this show is removed, which means the perfomer no longer shows up as booked for this show. (WAY # 2) I'm trying to be as precise as I can here about how the logic works in the code, without going through every single data related connection between the show and the act and the performer - so that I hope that both Scratch and Jon can follow me...

I'm actually OK with having 2 ways to book people and their acts into shows - I think it makes traversal of all the logic easier in a number of other places. (showing performer's their schedules, showing the bios of performers who are in shows, linking act tech info to shows, linking opportunities for rehearsal times to shows) - it would be easy enough to write the logic for this on the model level that lets an Act be smart about it self - it could have the power "book me for a show" where "me" is the act and then do the right thing if given a show id. And similarly "unbook me for a show" and we could let the act take it from there. Then the logic is in once, nice happy place and we can tap it for any thread...

So if I misunderstood what everyone else wanted on the conference call - great! That's awesome because it means the model as is is great, and doesn't need messing with, I just have some business logic changes to make to act approval.

— Reply to this email directly or view it on GitHub.

OK... let me try again, but I'm having a seriously hard time with being both precise and yet not technical.

We currently have two connections:

Way # 1 - that an act is directly a part of a show. Other stuff connects to both those things - performers perform acts, and shows are part of the whole scheduling system where they get allocated all the stuff they need - rooms, equipment, etc. One thing they need is people - performers, tech crew, other volunteers. Way # 1 is specifically that there is a connection between acts and shows and because of that, the performer who performs the act (which was part of the bid) is connected, via their act, to their show.

Way # 2 - in other cases, we are trying to work the human to scheduled item connection in a unified way - any event within the expo can be an Event - that includes a Show. Events get start times, durations and end times. Events get allocated stuff - people (workers), space (locations), things (equipment). This part of the design completely ignores the idea of an act because what's important here is the person who needs to be booked for whatever event we're talking about - and a show is just one of these things.

Does it make sense, then, that I can get from the person who is part of the performance to the show they are performing in two different ways??

If it doesn't, I will have to draw a picture, any other words are just going to muddy this issue.

bethlakshmi / GBE2

1 Performer 2 acts, chaos ensues #151

BurlExpo9