Closed tlvince closed 9 years ago
@johanneswilm, @readevalprint, @peritus, the team
property is pending two changes:
teamID
matches the team leader's memberID
team
is no longer static; members
are chosen per-surveyI've stubbed how it may look. Note the moving of _id
and _rev
on team
into each team.members
. On the app, the team
DB will be removed, in favour of a members
DB.
An alternative might be to change the members
type from array to object and index members by their designation, something like:
{
"team": {
"members": {
"Team Leader": {
"memberID": 1,
"firstName": "Alexei",
...
},
"Assistant": {
"memberID": 2,
"firstName": "Henry",
...
}
}
}
}
Thoughts?
Hey @tlvince why don't we remove the "teamID" and just refer to the ["Team Leader"].member_id
directly?
Also could you replace any keys with space to camel case or with underscores?
Sounds good. So it sounds like we can reduce it to:
{
"team": {
"teamLeader": {
"memberID": 1,
"firstName": "Alexei",
...
},
"assistant": {
"memberID": 2,
"firstName": "Henry",
...
}
}
}
ok, but isn't this going to be very restrictive once we have teams with 2-3 assistants? (not to think of teams with 2 team leaders).
According to https://github.com/eHealthAfrica/NutSurv-Mobile/issues/104#issuecomment-78875789, a team consists of three members; a leader, anthropometrist and assistant. We can revise the schema later if that changes?
And when you say "per survey" -- What do you mean by "survey"? There has been quite some confusion about that term. I think it was Tomasz/me who used "survey" to mean an individual interview, whereas Robert used it to describe the entire 90 survey on a specific theme (or the other way round). Will the teams change whenever they go to a new house or whenever they start a new 90-day survey cycle?
I've taken survey to mean an individual interview.
Yes, it consists of three members. But we know that is not the case often and the next version will likely require flexibility on that, so it's probably not a good idea to introduce spec changes that will make that harder, I would think. But Maybe it's OK if we just call them "assistant 1", "assistant 2", etc.
@tlvince so do the team members all sign in before each interview?
I think I would prefer having the array for team members (your first proposal) so that there won't be any problems extending it to hold several members with the same designation. But if you feel strongly about that, I guess we can always change it at a later stage, should we need to.
Is it really the case that a team can have more than one leader?
A constraint will be added such that the teamID matches the team leader's memberID
… doesn't make sense if that's the case.
/cc @cristinasantamarina
@tlvince Right now it cannot. Just think ahead of things that can happen. All we know is that the team structure is very different in each country.
No we need to just focus on on the specs we have now. We can modify the models in the next version of the project if it ever happens. On Mar 26, 2015 1:57 PM, "Johannes Wilm" notifications@github.com wrote:
@tlvince https://github.com/tlvince Right now it cannot. Just think ahead of things that can happen. All we know is that the team structure is very different in each country.
— Reply to this email directly or view it on GitHub https://github.com/eHealthAfrica/data-models/pull/27#issuecomment-86503577 .
Team members are listed once per day, not per interview. But their data should be available for each interview they conduct. +1 to @tlvince Teams will only have one Team Leader. We need to make this very plausible assumption; after all the Team Leader ID is the team ID. +1 to @readevalprint on adjusting to the spec we currently have.
OK, lets move forward and use:
{
"team": {
"teamLeader": {
"memberID": 1,
"firstName": "Alexei",
...
},
"assistant": {
"memberID": 2,
"firstName": "Henry",
...
}
}
}
That looks good
@readevalprint care to give this a once over?
Looks good!
Closes #22.