KLIK,

Again, the end of project estimate is just that, an estimate. We based it off what I had explained in this post:

https://secure.worldcommunitygrid.org/forums/...d,37594_offset,100#518333

Doing estimates manually for every project on a regular basis just to keep the estimated end date is not a wise use of our time, as it is just an estimate which has too many variables for many different projects. Again with many variables/projects we tried to come up with a way to estimate that would be somewhat fair to all the projects.

Also, It appears that starting with batch 3666 we will be getting back to flexible work units until the end. These will have batch counts of 100k work units instead of the 2k that we are seeing now.

Thanks,
-Uplinger

oh, God...you don't have it automated?!

forget it then...until you came with a script that does the ECD automatically!

then, they can fix the program...I've suggested (in other topic) the computing an ECD from the beginning of the project, not the "last loaded batches", like it has been done now!

Klik, which ever way they "cut the numbers", the only true time when we'll know exactly what the end date of the project will be, is literally when the last WU is returned.

What we do know, is that the MCM & UGM projects are nearing their end - and thus, that'll have an effect on the length of this project. Also, another two new projects have recently come aboard (FAHB & HST), so again, that'll have an effect on the end date of this project. There may be new projects coming on board that we don't know about - and/or there may be issues with projects that are already running on the grid.

Then, on top of that, the length of the WU's for this particular project can (and, by the sounds of it, will) change. Thereby, providing yet another parameter that will affect the end date of the project.

Furthermore, there may be other parameters totally outwith the control of WCG - such as funding issues for the OET project that may mean that it's curtailed sooner than originally planned (it wouldn't be the first - HPF2 being one example of this).

Thus, as suggested, take the ESTIMATED date as just that - an estimate. The techs have provided an insight into what's coming down the pipe, which will extend the project into next year. Also, they've provided an indication (i.e. the batch numbers), so use that as an indicator - just as Sgt Joe has done with his very useful and regular MCM updates.

You, just as everyone is freely able to do, can start a tracking thread that'll can provide a stab at giving a reliable end date of the project - so feel free to start one.

well, to have ECD in Research page in May 2016 is just: wrong logic in program creation! that's why I'm still posting here, so that techs can fix that...hopefully!

why?
today is 11/04/2016,
we have crunched from 03/12/2014
that is 495d
but we had about 2m pause of the project...so that's -60d, or 435d total crunching!
today last batch received (for me) is 2899
that makes average (from the beginning of the project) of 6,664 batches per day
with that you calculate the rest (5463 - 2899 / 6,664)...making it about 385d
so it with that little Excel or manual calc, you get ECD on last days of Apr 2017

certainly NOT May 2016!
but we'll have more than May 2017, as from batch 3666 goes normal progress of larger WUs...& last 200 are MONSTERS!

so techs, please use averages from the beginning of the project...they are "more certain" in calculations! all the speed up of the project will get subsidized from the:
- resend of WUs
- completed batches
& we'll still have more accurate result for the ECD!