Hi Willy,

are you playing with the database somehow today?
Most teams have a whole bunch of new members and members that left, but I don't think it really happened.

BoincSynergy doesn't show this in their stats.

Examples:

SETI.Germany here

BSy only has this feature per project, so only the big 4:

SETI.Germany @Seti in BoincSynergy

SETI.Germany @Einstein in BoincSynergy

SETI.Germany @CPDN in BoincSynergy

SETI.Germany @Rosetta in BoincSynergy

It doesn't fit, and other teams have the same hickup.

Willy,

It is general... our team stats are also ... I would say... a little messy. More than 30 people just vanished and we have all our little green arrows showing we jump from nothing to our current post...

Can you clarify? thx

I think I now the reason of this, I think it's related to what I posted here.

The changes I made will (when I switch to the new tables) have as a result that the last project that updates (during a stats update) will determine the name/country/url/team of a user. The current update goes from the oldest to the newest project (added to BS). I thought it was a bad idea to let the newest project determine these things, as it may not be configured yet. Therefor I reversed the update sequence from newest to oldest.

You may remember from a while back that I changed that a user could be a member of multiple teams in BOINC combined. That change and the one I did today resulted in the mass migration of users in teams in combined stats. Your members are not a member of your team in all projects (shame on them!).

If you look up the team member movement in the projects you'll see nothing special there.

Now I can do two things, both bad and good (to keep things confusing):
1: keep it as it is now. The teams members are stable now, you 'lost' members but you gained just as much. Unfortunately, team members in BOINC combined is not exact science. The good thing is that the oldest projects determine the things I mentions above, which I think is better.

2: change the sequence back. Your members in combined will be as before. But the newest projects determine the things mentioned.

I think you know my preference, but you are the users, you decide.

P.S. Of course BSy doesn't show this, they don't have the feature The projects themselves are equal.

P.S.2. I haven't imagined a result like this

I guess it would settle down after day but it didn't. I'll check for bugs first, if no bug is found (and I think I will not find any since the code for this page is unchanged) I'll change the update sequence back.

Together with Rytis I found a way to make the team of which a user is a member of consistent, regardless of the sequence used.

But it'll take a day or two to settle down.

Willy, could it be based on a "search & divide" per project approach??

Example: user AAA (with total 510 credits) is in two proyects:
project 1 with 500 credits in team XX
project 2 with 10 cretids in team YY

So: in team XX we can find on its "Total number of users" list : Mr AAA with 500 credits.

And in team YY the same Mr AAA is on its "Total mumber of users" list with 10 credits.

It will simplify our stats/team follow up!

It is just an idea... :-)

It will simplify it for you but make it incredibly more difficult for me.

I all explained it here.

I see.
But you mention (or your linked post) that the main source of complexity would be the historical traking of all team changes (in one project) for an user. I understand it is not possible!!. In my proposal I was not trying to track this historical. I was only trying to show the guys in their right pair "team- credit for proyect/s attached to this team" (disregarding if the credit was done or not in the actual team). In this sense you will see on your team list, all and every guy crunching (in a proyect) for your team. With a flavour of the ammounts he has done (ever)...

This, I would assume, would not be much difficult based on your DB architecture. It would improve team member stats showing actual total participation + additionally changes on the team users table would be only based on personal choices. The way it has been changed now, if the oldest (or a couple of the oldest) projects do not syncronize stats for 1 single day, team user dancing starts again.

I know you´ve already made up your mind this time... but please give it a thought.

Regads,
J.

+ it is on the newest projects (the ones you just start crunching) where people are more careful inserting their data (team & country).

On the first projects you try, you even do not know how to attach!!

evidence: countries stats are upsidedown. Now people will have to find their first seti (or einstein or whatever...) account they have not used for years, to update the right country on it!!!!

If my proposal cannot be weighted. I would vote to reverse the way the update is done. First the old, latest the newer (as it was before).
regards,
J.

It is still moving like hell... up & down every day...

It's back to normal.

To normalize it MySQL now assigns the user to the team that has the highest hash(team_name). This way MySQL can't assign a random team, and the same team will be selected until the user either quits the team, or joins a team with a higher hash.