[IBL] comments on mid-season ballot

[Noel Steere]

"The BF system will undoubtedly be refined over the course of time, let's not make perfection a requirement for having something better."

I'm just looking for "not seriously flawed". :-)

Something as simple as "next baserunner on/after BP" should work just fine.  You're still penalized by not being able to go at full strength on 3 days rest (am I reading that correctly?  You get to your BF, get relieved, and can go again at the same BF on 3 days rest?)

Re roster crunch:  The problem I'm concerned about is that by going to BF, we may end up without BF available to finish a full season.  As things currently stand, we can determine if we have enough IP to play the season.  If we go to BF, you won't know if you have enough BF to get the 9 * 81 + 8 * 81 innings needed at a minimum, since you could get unlucky and give up more baserunners than expected.  This is especially more likely for rebuilding teams, since by definition they'll have worse pitchers, which means they'll need to eat up more roster spots just to get enough IP to pitch the season.

Using a spot or two to churn through FA (i.e., what Chris is describing) might work, but that means our rosters are effectively reduced to 33 or 34, so it seems like some roster expansion is warranted if we go to BF.

Noel

Sent from my iPhone

> On Jul 25, 2014, at 7:02 PM, Sean Sweda <sweda at ibl.org> wrote:
> 
> 
>> On Jul 25, 2014, at 7:11 PM, Noel Steere wrote:
>> 
>> As I mentioned to Sean separately, I think at a minimum we need to include some form of variability to starter fatigue from the get-go, as that's currently the only instance were the offense knows exactly when a reliever will fatigue (I say "only", but it's also every game :-)).
> 
> While some may consider variable fatigue a "feature" of the old PtP rules, as it's also a "bug" that allows starting pitchers to throw an unlimited number of innings as long as they don't allow the magic number of baserunners.  The BF system will undoubtedly be refined over the course of time, let's not make perfection a requirement for having something better.
> 
>> I also think the BF rest rules, while much more realistic, will along with the possible new rule about roster restrictions on dropping/adding players cause some serious roster crunches due to an inability to get enough innings.  If we're going to more closely emulate MLB usage (not even sure that's such a great idea for a sim, since MLB bullpen strategies are so lopsided towards fewer and fewer BF per appearance), we should more closely emulate their resources and expand the rosters to 40 players.
> 
> The release restrictions won't affect anyone unless they are trying to cycle through a bunch of low-PT players in the free agent pool, and even then it simply means they will have to get slightly less usage out of a guy before moving on to the next card.
> 
> I managed my team using the new BF rules for the first 5-6 weeks and I had absolutely no problem running my relievers over 100%, you just can't do it as ludicrously fast as with the old rules (e.g. RP pitch 5 innings across consecutive games).  I don't see any reason to think we would need additional roster spots, though I suspect it will require some people to adopt a different configuration of their 25-man active roster.
> 
>> Re Stadiums:  A lot of analysts use 3 year averages, which would help with variance.  Personally, I think we should do 3 year weighted averages for everything, including player cards, with current year weighted 4, last year a 2, and two years ago a 1.  Rookies and two year players get a AAA player sort of stat line for years before they came up.  But I know that's really a conversation for another time. :-)
>> 
>> Still, three year averages for parks is something to consider.
> 
> FYI - IBL park effects are already a weighted average of the previous 2 seasons (2/3 most recent season, 1/3 previous season).  I doubt adding another year will stabilize the park effects enough to suit those who want their MLB park to remain relatively static.
> 
> Sean