ProjectEvent concept

[mo-nathan]

It's not unusual for Projects to consist of a series of events. Obvious examples are annual forays like NAMA, NEMF or Telluride. Also lots of clubs have annual forays or may want to track all the forays that happen in a local area.

The original idea was to move the time and location constraints currently in Projects to their own model which has a many to one relationship with Projects. There would then be an Event(s) tab for Projects. If there's just one event, then it would show info about that event. If there is more than one, then it would allow drilling into an event form an index table. The ProjectEvent#show page would and show the event info as well as Observations, Names, and Constraint Violations for that ProjectEvent. The header for the page would be based on the associated Project. Members and Admins would remain at the Project level.-

[mo-nathan]

Should observations and other objects be associated with Projects or ProjectEvents? I think ProjectEvents, but maybe not. What should happen if a user wants to create ProjectEvents that overlap in both time and location? The other challenge is the granularity of events. Would users want to filter both by a weekend and then later by a specific walk and different but related "events". If ProjectEvents are really just filters on Project observations, that seems better. Filtering by date seems reasonable. Filtering by location seems a lot harder. The motivating functionality is the idea of reusuable Field Slips. It's clear that we want to be able to generate lists of names and observations for a given event.

[mo-nathan]

I'm now thinking that we think of "ProjectEvents" as filters and separate the location filters from the date filters. The idea would be you could add time ranges (like when a NAMA foray is happening) and filter by that. You could also filter by any locations associated with the observations of the project. This would let you show all the observations associated with the specific weekend of an event or by a given walk during the event. The only potentially desirable thing would be to filter by a larger location (say "Cape Cod") rather than a walk. When there's a singular larger location this seems reasonable from the "constraint" perspective, but when there are events in very different places that are associated it gets a lot harder. One possibility is that a project could be "open" for observations for a particular date/location combo. This could allow you to warn folks who are adding observations at a particular time, but the concept of "Constraint Violations" gets a lot harder to understand and track.

[mo-nathan]

If you could filter by both date and locations that might be sufficient. To find "outliers" you would probably want to be able to constrain by date and then find the observations that are within some location and any that are outside that location. I think that gives you the ability to curate the observations. If you could search for an arbitrary date range you could also find date outliers.

[mo-nathan]

A totally different way of thinking of this problem is allowing Project to have a set of Projects. Subproject can then inherit or override properties from their "parent" Project. This then gets into the questions like is it a strict hierarchy? Could Projects have more than one "parent" Project (e.g., a NAMA and MSA meeting happens in the same place at the same time)? Can Projects contain themselves? (Don't see a good reason why, but it is potentially difficult to determine depending on how deep the Project graph gets.)). This resolves some interesting puzzles like what if you want different banners for different years of a project?

Another approach would be to leave Projects as they are at the moment and allow the Field Slip prefix to be reused. We still might want reporting over the set of Projects that have the same Field Slip prefix. FIeld Slip reuse potentially makes it ambiguous which Project a new Field Slip should get associated with. Project constraints should help with the ambiguity issue, but it remains possible. Maybe that's no a huge issue given that users can already choose a different Project if they want. I can imagine issues if there is some big bioblitz happening on the same date and the regions overlap in some way (e.g., the box for VT and NH overlap). However, this is a problem with any of the solutions.

[mo-nathan]

Another interesting question is how does this impact project membership and administration. Presumably the "Project Event" and "Project Filter" ideas would have a shared set of members and admins (that could of course change over time). The "Projects within Projects" idea provides some flexibility since you could enable members of ancestor projects to be members of subproject or not as well as allowing users to join or be added to specific projects. This makes the member concept a lot more complicated, but I'm not sure it provides any real value. The idea of "Reusable Prefixes" implies that the membership for the different projects are completely independent.

[JoeCohen]

My head is swimming from trying to think about all this in the abstract. What if constraints were strict? (Unless all of dates, location/gps, membership met constraints, the Observation doesn't get added to the Project Event (or whatever we call it)?

[mo-nathan]

After more discussion, the current plan is to leave Projects as they are, but allow the field_slip_prefix to be reused between projects. To avoid ambiguity the association between a project and an observation will happen after the observation gets saved so project constraints can be checked. If it is ambiguous, then the user will be given a UI to decide what to do. Once there is more than one project using the same field_slip_prefix (or even some related projects that want this feature), we can add the concept of a ProjectCollection and do reporting at an aggregate level. There isn't a burning use case for this, so I'm going to pursue improving the field slip form entry process or maybe the mobile app.