Update to VP Congress Schedule

Recursive

Already Looping
Moderator
Supporter
Joined
Dec 19, 2017
Messages
6,128
Location
Antarctica
Hey everyone,

First, I'm sorry for my absence. The electricity and heating in my home broke down and I had a lot of missed work to catch up on. I will be starting the Voting Phase for Session #3 tonight and extending it to ensure there are 7 days of voting time.

Second, thank you for your participation in the VP Congress!

It has come to my attention (after feedback from several community members) that the current schedule of the VP Congress is not working in the best interests of the community. To be more specific, having a VP Congress session every month is too hectic of a pace for change. It results in the following problems:

Lack of communication regarding proposals. The original intention was for proposers to communicate with the community, discuss problems, refine ideas, coordinate with sponsors, and then make proposals. Not a lot of this has happened, and a lot of it has to do with the fact that there is a constant debate over proposals going on, so people have less time to breathe and adjust to changes.

Sponsor and voter fatigue. For the same reason, the constant debating can get exhausting for members of the community.

Judgement calls regarding proposals affecting the same game mechanic. In this third session of the VP Congress, because two proposals affected the Forge building, which is also being modified by a proposal that was passed in the last VP Congress but was not yet implemented, they had to be vetoed under current rules, while a counterproposal which had a similar rationale but didn't affect the Forge was allowed to go through - which allows for gaming of the rules. In addition, having to make all these judgement calls is unfun for me, for the people who get their proposals vetoed, and for the supporters of those proposals. These judgement calls will always be subjective, and thus susceptible to human error and frustration.

(In the interests of the health of the system, I'm going to veto the counterproposal - sorry, @Legen).

Difficulty keeping track of changes. This is true for the community, for people making proposals, and for coders on GitHub. The pace at which changes are being made and proposed is too fast to effectively keep up with, from my observations.


To solve these problems, I am making the following changes to the VP Congress:
1) VP Congress Sessions will take place every other month, instead of every month. After this session (Session #3) has concluded, the month of February will be a cooldown period during which proposals are implemented. No proposals can be made until March 1st. This should allow more time to breathe, implement sponsored proposals, flesh out and discuss changes more, and generally make life easier for everyone involved in running the show. Session #4 will take place during March, then April will be a cooldown month, then Session #5 in May, etc.

This also avoids having a VP Congress Session in the month of February, so all months should have a similar amount of time for the Voting Phase. And if problems like those of this month hinder me from starting a phase on time, there is some wiggle room in the schedule due to the cooldown month.

While this may be disappointing, it is still more democracy than we had before, and I believe this will lead to a higher standard of quality, a smoother process, and most importantly, it will be sustainable in the long term. In addition, I am making the additional changes below to make up for it.


2) No more ratification of proposals and Ratification Options. With sessions taking place every other month, it is simply too much of a pain to do ratification, and Ratification Options become unnecessary. In our first ratification vote, not a single proposal was rejected and fewer people voted in it because it was a giant poll. In addition, it's hard to effectively express your opposition to a change you don't like for ratification with the current format.

As a result, if you don't like a change that was added, you can simply make a proposal to revert it in the next VP Congress Session, after it is implemented. This is ratification, in a sense, but instead of being automatic, a community member has to propose it (meaning changes which are universally liked, or which no one cares enough to propose to revert, don't need to be ratified).

However, balance changes which are made on GitHub by modders will still be ratified. They will be treated as a proposal in the Congress session following their functional implementation, and a thread will be created to discuss that particular change to separate it from the rest.


3) Strict sponsorship deadlines. If the proposal you sponsored is not implemented by the end of the cooldown month following the session in which you sponsored it - it is vetoed, no exceptions. The work can still be done, but others can make proposals affecting this, and the change will need to be ratified as if the modder made a balance change on their own initiative. Be sure not to bite off more than you can chew.

This will eliminate all issues relating to queued proposals conflicting with new proposals, and remove all judgement calls about whether or not two proposals affect the same game mechanic, simplifying the process greatly.

This rule will go into effect beginning in VP Congress Session #4.


4) Guaranteed release at the end of the cooldown month. While releases can happen at any time, a release will happen at the end of the cooldown month, including all implemented proposals that were sponsored in the previous session.


Thanks for your understanding, and feel free to provide any feedback on the changes below. They will be added to the VP Congress Guide shortly.
 
Hi, great changes! I wondered how the congress will be refined and this set of changes seem like a step in the most positive direction. It will hopefully avoid further drama that has been expressed by some members of the community.
 
I like that the sessions will take place every other month, instead of every month. Because there are lots of proposals hasn't been implemented yet. Some of them are big changes and clearly affect the pace of the game. Also not be a pain in the butt for modmodders to check every single update every months.
 
I think the biggest problem is that we are making porposals before passed proposals are even in the game via a new version. So, it is hard to see the effects of the passed proposals.
You can't propose to change what has passed but not implemented.
 
Great change! I honestly think even every other month might be to much. Games take a long time to play and rapid change is not necessarily needed in a mod as refined as VP. Also it puts a strain on modders who do the heavy lifting as you also noted.
 
Judgement calls regarding proposals affecting the same game mechanic. In this third session of the VP Congress, because two proposals affected the Forge building, which is also being modified by a proposal that was passed in the last VP Congress but was not yet implemented, they had to be vetoed under current rules, while a counterproposal which had a similar rationale but didn't affect the Forge was allowed to go through - which allows for gaming of the rules. In addition, having to make all these judgement calls is unfun for me, for the people who get their proposals vetoed, and for the supporters of those proposals. These judgement calls will always be subjective, and thus susceptible to human error and frustration.

(In the interests of the health of the system, I'm going to veto the counterproposal - sorry, @Legen).
Can you clarify the 'gaming of the rules' part?

As I understand, the rules involved in the Bronze Working debates were very clear and didn't have room for subjective interpretation. The complaints that kept being raised about it revolved mainly around three points:
  • A counterproposal shouldn't be allowed to continue if the original proposal (and the other counterproposals) gets a veto.
  • The changes to the Forge in the original proposal doesn't count as modifying the same mechanic as the changes to the Forge in the other proposal under implementation.
  • A proposal can't be submitted until 30 days after a previous proposal that modifies the same mechanic is implemented.
The first one has no rule backing it up. Nothing in the rules mentions that a counterproposal can only exist as long as the original proposal isn't veto'ed, or anything similar to that. This complaint is adding a rule to the system due to the complainer's own interpretation, rather than based on any specific rule. And this is a dangerous rule to add, as this one does allow gaming of the rules. I mentioned before:

"If a proposal being removed implies veto on its counterproposals, then the original proposer can mess with the counterproposals by either withdrawing it at the last moment, or amending it in a way that would result in a veto. It doesn't need to be with bad intentions, but it would nonetheless throw out counterproposals that would otherwise be normal proposals had their authors proposed first. That would also mean you're better rushing your proposals, so that your ideas don't end at at the mercy of someone else's intention, or attention to previous proposals; taking your time to think through before proposing becomes a risk."

And rushing proposals is something that I'm already considering next session due to this situation. I was already working on a proposal for Bronze Working before session 3 started, which can be traced back to the discussions on the (2-04) proposal, and was taking my time to refine it instead of proposing something rushed. And I suspect that, had I rushed instead and made it a proposal before someone else proposed something related, instead of ending as a counterproposal, this complaint wouldn't have been raised and my proposal wouldn't have been veto'ed in response. So, rushing a proposal is safer than taking time to refine it under this interpreted 'rule'. It adds pressure on everyone to lower the quality of their proposals in favor of preventing being subject to someone's else proposal, and that in turn can result in more vetoes due to the lower quality coming from less attention to the rules when proposing and, consequently, more judgement calls on your part. I don't see how this is supposed to be healthy for the system, or fun for anyone.

The second complaint was that the original proposal changes the cost and tech requirement of the Forge, while the proposal under implementation changed only the bonus to mines, so they don't count as the same game mechanic. However, the rules had it clearly specified in the following lines:
A Note on "Game Mechanics"
This will generally be interpreted narrowly at the Host's discretion, but some examples:

Two proposals which modify the Granary will be considered to modify the same game mechanic.
So, it leaves no room for subjective interpretation for the Forge's case. The complainer's point that your judgement was subjective and unjust (and that, therefore, my proposal should receive the same treatment) isn't backed by the rules, they leave no room for argument or interpretation.

The third one is a complaint that isn't backed up by the rules either. The closest related rules are:
The proposal must not affect the same game mechanic as a proposal in the Proposal Queue (awaiting implementation into a release). See Proposal & Ratification Queues.
The proposal must not be identical (or very similar to) a proposal that was rejected by the community in last month’s Voting Phase, or which was overturned during ratification within the past 30 days. A substantially changed proposal on the same game mechanic is allowed.
The first rule only specifies about a proposal awaiting implementation, while the second rule only specifies about proposals that failed during the voting phase (either never approved to be implemented, or already implemented but rejected during ratification). As such, a proposal can't be subjected to a veto under both rules at the same time. Since the 30-day-cooldown period is only mentioned in the second rule, which neither says anything about proposals under implementation, nor about a proposal/implementation that has yet to be voted, then the complaint is a misinterpretation of how the rules work.

And this misinterpretation seems to be where the reference to 'gaming of the rules' come from. Under the idea that the 30-day period can be gamed, two possibilities of gaming the rules exist:
  • That my counterproposal serves to keep the complainer from proposing the veto'ed proposal next session;
  • That the sponsor of the Forge's proposal under implementation (which was the basis of the veto) has delayed it to mess with the complainer's proposal;
On the first possibility, I already stated that I had the intention of implementing beforehand (already done locally, only three lines of code) for next release (so that the complainer can propose immediately after), and that the 30-day cooldown mentioned doesn't apply to already implemented proposals. If the 30-day-cooldown period existed as complained, then ratification options wouldn't be possible in the first place, which is what the complainer's proposal would be.

On the second possibility, it was discussed that it would involve dll coding for an elegant implementation, so time to implement it was expected; it isn't reasonable to expect ill intent from that sponsor. And again, the 30-day-cooldown period doesn't exist after it gets implemented, so the complainer wouldn't be prevented from proposing again on February due to this one. Note that a veto on my proposal would already be purposeless if the 30-day-cooldown after implementation existed, since the complainer would still be unable to propose on February due to the one being implemented entering this 30-day-cooldown anyway.

Closing this post, I don't see how your judgement call was subjective, the rules were very clear about it. And I don't see the 'gaming of the rules' as being a result of the rules; rather, I see them as existing only within the misinterpretation of the rules on the complainer's side, rather than from the actual system. I approve the changes nonetheless, I just don't agree on the case about the judgement call among the problems, nor on the resulting veto. I suppose the latter was expected, anyway.
 
Can you clarify the 'gaming of the rules' part?

As I understand, the rules involved in the Bronze Working debates were very clear and didn't have room for subjective interpretation. The complaints that kept being raised about it revolved mainly around three points:
  • A counterproposal shouldn't be allowed to continue if the original proposal (and the other counterproposals) gets a veto.
  • The changes to the Forge in the original proposal doesn't count as modifying the same mechanic as the changes to the Forge in the other proposal under implementation.
  • A proposal can't be submitted until 30 days after a previous proposal that modifies the same mechanic is implemented.
The first one has no rule backing it up. Nothing in the rules mentions that a counterproposal can only exist as long as the original proposal isn't veto'ed, or anything similar to that. This complaint is adding a rule to the system due to the complainer's own interpretation, rather than based on any specific rule. And this is a dangerous rule to add, as this one does allow gaming of the rules. I mentioned before:

"If a proposal being removed implies veto on its counterproposals, then the original proposer can mess with the counterproposals by either withdrawing it at the last moment, or amending it in a way that would result in a veto. It doesn't need to be with bad intentions, but it would nonetheless throw out counterproposals that would otherwise be normal proposals had their authors proposed first. That would also mean you're better rushing your proposals, so that your ideas don't end at at the mercy of someone else's intention, or attention to previous proposals; taking your time to think through before proposing becomes a risk."

And rushing proposals is something that I'm already considering next session due to this situation. I was already working on a proposal for Bronze Working before session 3 started, which can be traced back to the discussions on the (2-04) proposal, and was taking my time to refine it instead of proposing something rushed. And I suspect that, had I rushed instead and made it a proposal before someone else proposed something related, instead of ending as a counterproposal, this complaint wouldn't have been raised and my proposal wouldn't have been veto'ed in response. So, rushing a proposal is safer than taking time to refine it under this interpreted 'rule'. It adds pressure on everyone to lower the quality of their proposals in favor of preventing being subject to someone's else proposal, and that in turn can result in more vetoes due to the lower quality coming from less attention to the rules when proposing and, consequently, more judgement calls on your part. I don't see how this is supposed to be healthy for the system, or fun for anyone.

The second complaint was that the original proposal changes the cost and tech requirement of the Forge, while the proposal under implementation changed only the bonus to mines, so they don't count as the same game mechanic. However, the rules had it clearly specified in the following lines:

So, it leaves no room for subjective interpretation for the Forge's case. The complainer's point that your judgement was subjective and unjust (and that, therefore, my proposal should receive the same treatment) isn't backed by the rules, they leave no room for argument or interpretation.

The third one is a complaint that isn't backed up by the rules either. The closest related rules are:


The first rule only specifies about a proposal awaiting implementation, while the second rule only specifies about proposals that failed during the voting phase (either never approved to be implemented, or already implemented but rejected during ratification). As such, a proposal can't be subjected to a veto under both rules at the same time. Since the 30-day-cooldown period is only mentioned in the second rule, which neither says anything about proposals under implementation, nor about a proposal/implementation that has yet to be voted, then the complaint is a misinterpretation of how the rules work.

And this misinterpretation seems to be where the reference to 'gaming of the rules' come from. Under the idea that the 30-day period can be gamed, two possibilities of gaming the rules exist:
  • That my counterproposal serves to keep the complainer from proposing the veto'ed proposal next session;
  • That the sponsor of the Forge's proposal under implementation (which was the basis of the veto) has delayed it to mess with the complainer's proposal;
On the first possibility, I already stated that I had the intention of implementing beforehand (already done locally, only three lines of code) for next release (so that the complainer can propose immediately after), and that the 30-day cooldown mentioned doesn't apply to already implemented proposals. If the 30-day-cooldown period existed as complained, then ratification options wouldn't be possible in the first place, which is what the complainer's proposal would be.

On the second possibility, it was discussed that it would involve dll coding for an elegant implementation, so time to implement it was expected; it isn't reasonable to expect ill intent from that sponsor. And again, the 30-day-cooldown period doesn't exist after it gets implemented, so the complainer wouldn't be prevented from proposing again on February due to this one. Note that a veto on my proposal would already be purposeless if the 30-day-cooldown after implementation existed, since the complainer would still be unable to propose on February due to the one being implemented entering this 30-day-cooldown anyway.

Closing this post, I don't see how your judgement call was subjective, the rules were very clear about it. And I don't see the 'gaming of the rules' as being a result of the rules; rather, I see them as existing only within the misinterpretation of the rules on the complainer's side, rather than from the actual system. I approve the changes nonetheless, I just don't agree on the case about the judgement call among the problems, nor on the resulting veto. I suppose the latter was expected, anyway.
Thanks for the feedback.

To clarify, I do not think you did anything wrong or that you 'gamed the rules', so I apologize if I gave that impression - I noted when vetoing the proposal that it was a problem with the system.

This is a case where there was nothing wrong with your proposal under the existing rules, but the existing rules created a system which I don't believe is operating in the best interests of the community. This is my doing, not yours.

To be specific, under the existing system, depending on the timing when a queued proposal is implemented, players are given more or less freedom of choice when it comes to proposals, and varying amounts of time to make proposals, which is unfair to everyone.

If the community believes there is a specific problem, they shouldn't be pushed into voting for a specific change because other options were vetoed due to sponsors not having pushed their changes yet, or a release not having been made yet. That is my reasoning for vetoing it. Your proposal itself isn't problematic, nor do I believe you acted with any malicious intent, and you can propose it again next session.

The existing system pressures sponsors and proposers to work on a rushed timeline, as you pointed out, which is neither healthy nor sustainable, in my opinion. The problem wasn't clear to me earlier, but it is now. These early sessions were an experiment designed to identify problems like this. Hopefully, this should be the last major adjustment required.

While the rules for what constitutes the same game mechanic were relatively clear, my decision to go with that standard is a subjective judgement - and there are other areas, such as say, religion, where the distinction is murkier. While I decided last time to go with a narrow interpretation, I think going with a narrow interpretation is contributing to modders having trouble keeping track of changes and players having trouble understanding and evaluating the balance impacts of changes. For this reason, I think a cooldown period and strict sponsorship deadlines is a good way to solve this problem.

This is not me acquiescing to complaints about your proposal, this is me recognizing an underlying systemic issue that prompted those complaints and was also having negative effects elsewhere. I understand why you're unhappy with the decision - as I said, feel free to propose it again in the next session.
 
Last edited:
. To be more specific, having a VP Congress session every month is too hectic of a pace for change. It results in the following problems:
Well, I hate to say I told you so...

But jokes aside looks like good changes, I mean no one expected it to be perfect first try.
I mean, even every two months might be too quick. I think back in *the before times* changes probably happened at about a 3 month schedule. Maybe I'm just slow though.
 
Last edited:
To clarify, I do not think you did anything wrong or that you 'gamed the rules', so I apologize if I gave that impression - I noted when vetoing the proposal that it was a problem with the system.

This is a case where there was nothing wrong with your proposal under the existing rules, but the existing rules created a system which I don't believe is operating in the best interests of the community. This is my doing, not yours.

To be specific, under the existing system, depending on the timing when a queued proposal is implemented, players are given more or less freedom of choice when it comes to proposals, and varying amounts of time to make proposals, which is unfair to everyone.

If the community believes there is a specific problem, they shouldn't be pushed into voting for a specific change because other options were vetoed due to sponsors not having pushed their changes yet, or a release not having been made yet. That is my reasoning for vetoing it. Your proposal itself isn't problematic, nor do I believe you acted with any malicious intent, and you can propose it again next session.
You didn't give that impression, no worries.

The main concern is that, as it is, a proposal or counterproposal can be veto'ed on the grounds that it wouldn't be fair to the ones that did get a veto, rather than on its flaws. In this case, it is particularly concerning because the proposal under implementation was at first affecting a mechanic (Forge) that isn't among the core mechanics in the rationale of the new ones (Bronze Working and iron reveal); the Forge itself wasn't mandatory in this counterproposal chain and could, in theory, be replaced with a different building, like the Water Mill. What prevents someone from looking at a proposal he doesn't like in this session and complain that it should get a veto because he couldn't propose something that would use an unrelated mechanic, and succeed? Just a quick look at the ratification queue and I can already see two ways in which the current proposals can undergo this treatment; this is a form of rule gaming that this veto allows for and I don't approve that.

Also, there's the issue that this whole situation may not have appeared if the order of the proposal chain was different, with mine being the first proposal and the veto'ed ones being the counterproposals, as that was part of the complaints. No rule says that a veto on the first proposal implies a veto on its counterproposals, but it was part of the first complaints, and I'm concerned of that becoming an unofficial rule with this veto. At least, I'd like a rule clarification preventing that in the system.

On my proposal's veto, don't bother with reverting it; I just want it to be judged under its own merits and demerits, and I don't think it will be possible during this session. Problem is, I'm not sure it will be next session, given how it all went and how the core mechanics involved in the proposals turned out to be so emotionally charged. The rule clarification above is part of addressing that, but I don't expect it to solve it.
 
You didn't give that impression, no worries.

The main concern is that, as it is, a proposal or counterproposal can be veto'ed on the grounds that it wouldn't be fair to the ones that did get a veto, rather than on its flaws. In this case, it is particularly concerning because the proposal under implementation was at first affecting a mechanic (Forge) that isn't among the core mechanics in the rationale of the new ones (Bronze Working and iron reveal); the Forge itself wasn't mandatory in this counterproposal chain and could, in theory, be replaced with a different building, like the Water Mill. What prevents someone from looking at a proposal he doesn't like in this session and complain that it should get a veto because he couldn't propose something that would use an unrelated mechanic, and succeed? Just a quick look at the ratification queue and I can already see two ways in which the current proposals can undergo this treatment; this is a form of rule gaming that this veto allows for and I don't approve that.

Also, there's the issue that this whole situation may not have appeared if the order of the proposal chain was different, with mine being the first proposal and the veto'ed ones being the counterproposals, as that was part of the complaints. No rule says that a veto on the first proposal implies a veto on its counterproposals, but it was part of the first complaints, and I'm concerned of that becoming an unofficial rule with this veto. At least, I'd like a rule clarification preventing that in the system.

On my proposal's veto, don't bother with reverting it; I just want it to be judged under its own merits and demerits, and I don't think it will be possible during this session. Problem is, I'm not sure it will be next session, given how it all went and how the core mechanics involved in the proposals turned out to be so emotionally charged. The rule clarification above is part of addressing that, but I don't expect it to solve it.
That is not the case, and it is not a precedent I'm setting for later on. It's one-time.
 
You didn't give that impression, no worries.

The main concern is that, as it is, a proposal or counterproposal can be veto'ed on the grounds that it wouldn't be fair to the ones that did get a veto, rather than on its flaws. In this case, it is particularly concerning because the proposal under implementation was at first affecting a mechanic (Forge) that isn't among the core mechanics in the rationale of the new ones (Bronze Working and iron reveal); the Forge itself wasn't mandatory in this counterproposal chain and could, in theory, be replaced with a different building, like the Water Mill. What prevents someone from looking at a proposal he doesn't like in this session and complain that it should get a veto because he couldn't propose something that would use an unrelated mechanic, and succeed? Just a quick look at the ratification queue and I can already see two ways in which the current proposals can undergo this treatment; this is a form of rule gaming that this veto allows for and I don't approve that.

Also, there's the issue that this whole situation may not have appeared if the order of the proposal chain was different, with mine being the first proposal and the veto'ed ones being the counterproposals, as that was part of the complaints. No rule says that a veto on the first proposal implies a veto on its counterproposals, but it was part of the first complaints, and I'm concerned of that becoming an unofficial rule with this veto. At least, I'd like a rule clarification preventing that in the system.

On my proposal's veto, don't bother with reverting it; I just want it to be judged under its own merits and demerits, and I don't think it will be possible during this session. Problem is, I'm not sure it will be next session, given how it all went and how the core mechanics involved in the proposals turned out to be so emotionally charged. The rule clarification above is part of addressing that, but I don't expect it to solve it.
a) the rules changes don't have anything to do with vetoes.
b) the rules changes remove the issue with the system that caused the vetoes; therefore they won't happen again.
 
a) the rules changes don't have anything to do with vetoes.
b) the rules changes remove the issue with the system that caused the vetoes; therefore they won't happen again.
That's exactly the point. It shouldn't happen, and I want the rule changes to make it clear. The rule changes address two of the three points I mentioned before, I just want the remaining one to also be addressed.

Again, I approve the changes and understand that the goal is to fix an issue with the system. I just think that there is one issue left unaddressed, the one about counterproposals being tied to the original proposal being veto'ed, as this interpretation does allow the rules to be gamed. I just want the rules to include a clarification on this point.
 
I really like the idea of having the extra month in stasis for testing new features, etc as work schedule doesn't really allow for alot of playtime to settle in for a good session of 4x games (RTS games I don't mind being quick, turn based I enjoy long term gameplay)

I'd personally be happy for a quarterly patch cycle, which would give ample discussion time instead of the first impressions before the voting cycle gets underway. It would also allow any bugs to be hotfixed along the way, minor balance edits to be implemented.

The main concern I have going forward is that you guys (Devs and Sponsors of additions) will end up burning out over time and am quite happy with the cycle being given an extra month. The amount of proposals is quite staggering... It took me a week to read them all for the first cycle, that was just the proposals not the comments!
 
All of these are very good changes. The cooldown period can also be used for the discussion and refinement of ideas that can then be molded into proposals in the next session. To this end, maybe a subforum that can be used for discussions and polls would be good?

I really like the idea of having the extra month in stasis for testing new features, etc as work schedule doesn't really allow for alot of playtime to settle in for a good session of 4x games (RTS games I don't mind being quick, turn based I enjoy long term gameplay)

I'd personally be happy for a quarterly patch cycle, which would give ample discussion time instead of the first impressions before the voting cycle gets underway. It would also allow any bugs to be hotfixed along the way, minor balance edits to be implemented.

The main concern I have going forward is that you guys (Devs and Sponsors of additions) will end up burning out over time and am quite happy with the cycle being given an extra month. The amount of proposals is quite staggering... It took me a week to read them all for the first cycle, that was just the proposals not the comments!
I agree, having one additional month for play-testing between a release and the next proposal phase would make it possible to evaluate the changes made in each voting session better, and it would make sure that they are taken into account in the new proposals.
 
Well, I hate to say I told you so...

But jokes aside looks like good changes, I mean no one expected it to be perfect first try.
I mean, even every two months might be too quick. I think back in *the before times* changes probably happened at about a 3 month schedule. Maybe I'm just slow though.
:dunno: You may be right. But the intensive field test helped identify a lot of problems, allowing them to be fixed within a few months rather than a year or longer. I'm following Gazebo's philosophy of making big changes and then making adjustments until the system functions as desired.
 
I mean, even every two months might be too quick. I think back in *the before times* changes probably happened at about a 3 month schedule. Maybe I'm just slow though.
The truth is...its always been sporadic. We have had months of inactivity followed by a new version almost every week for a month or two. Your probably right that overall its closer to every 3ish months or so.
 
I miss getting new versions already...
 
Top Bottom