Thank you for reporting this issue. The Department of Public Works will now begin its investigation into the matter.

Traffic Foreman assigned this issue to Traffic Signal Engineer

The signal was set to skip Winooski in the absence of traffic after cameras were installed. The angle of the camera for southbound Winooski is constrained by its mounting point adjacent to the stop bar, preventing a wider angle of view. This is the first reported miss that I am aware of. The signal has been set to change every time, with or without traffic on Winooski. The cameras remain useful by allowing a change sooner without traffic, or holding the light green longer with traffic. The Department of Public Works has resolved this request. Thanks for helping to keep Burlington a great place to live and work.

Why was my comment blocked by rejections on 8/1? I didn't swear or say anything nasty! I'd like to know why!

The problem was solved, issue was answered and closed.

This content is currently blocked. The content is either under review by SeeClickFix or has been confirmed by SeeClickFix for violation(s) of SeeClickFix Terms of Use (https://www.civicplus.com/terms-of-service). Content that aligns with SeeClickFix Terms of Use will be posted, and content that does not align with our Terms of Use will not be permitted for public viewing.

The problem was solved, issue was answered and closed.

Thanks for fixing this request!

This content is currently blocked. The content is either under review by SeeClickFix or has been confirmed by SeeClickFix for violation(s) of SeeClickFix Terms of Use (https://www.civicplus.com/terms-of-service). Content that aligns with SeeClickFix Terms of Use will be posted, and content that does not align with our Terms of Use will not be permitted for public viewing.

The problem was solved, issue was answered and closed.

This content is currently blocked. The content is either under review by SeeClickFix or has been confirmed by SeeClickFix for violation(s) of SeeClickFix Terms of Use (https://www.civicplus.com/terms-of-service). Content that aligns with SeeClickFix Terms of Use will be posted, and content that does not align with our Terms of Use will not be permitted for public viewing.

The problem was solved, issue was answered and closed.

Thank you for fixing the traffic signal to cycle every time whether there is traffic detected on Winooski or not. However, you did not respond to my request for fixes to the pedestrian signal. During off hours I would like to see the pedestrian beg button actually accelerate the change in signals and initiate a walk signal in advance of the green. Currently it does not appear to accelerate the cycle.

I agree and think ALL pedestrian buttons should either respond immediately, or within say 30 seconds, of being pushed. It's so very difficult to time the cycles for pedestrians and cyclists as there's such a wide range of speeds at which persons of differing abilities travel over the varying terrain and condition of the sidewalks/bike lanes. And it's cruel to force pedestrians and cyclists to wait for such long cycles in all of Burlington's weather--especially these sunny, hot days. How are pedestrian cycles currently initiated (cameras/buttons/set cycles?) and what are the citywide parameters for timing of all of our pedestrian cycles?

And when I asked the traffic control engineer the question my comment was blocked by rejections.. does anyone have any idea why?

The name of this forum is See, Click, FIX (emphasis mine). Being notified of something broken makes this forum a valuable asset. It is not called See, Click, EXPLAIN. Very frequently, I choose to augment my answer with additional technical information, over and above the simple, dry, "It's fixed" response. I do this because it can add some insight and context to the issue, and it is generally a positive thing to share. But not always. This issue at its core is about a signal that did not change for a bicycle. This was a high-priority thing that was responded to rapidly. Wrapping a technical question around it does not obligate an answer to the technical question at the same level of urgency as fixing the actual problem. Any other questions, from the broad view of this issue, are moot once the immediate problem is solved. It is inappropriate to reopen this issue and demand to be heard. It is as if an attempt is being made to conflate the importance of fixing a stuck signal with answering a probably unanswerable question. They are not on the same level. I judge the question as possibly unanswerable because of the context in which it is asked. The clues, from past experience, tell me that answering is very likely not going to be productive. No explaining of how things work and why they work that way is likely to change the mind of the requester. There is too much material to cover and this forum is not the place to do it. At least that is what I make of it and why I chose not to answer. See? I am sharing again. Properly, a request for a new feature should be its own separate request. There it can sit for a while awaiting a technical answer. Which can take a while to develop. It would be classified as an "improvement request," not a "problem" requiring an immediate response. A technical question is going to have to wait anyway, because this week is filled with some intensely technical tasks that have to be completed ASAP. Reopening an issue to argue a question when the problem has been solved is an abuse of this system. Ask politely, but leave it closed, and I might take the time to explain. Understand that this week is SUPER busy. Conversely, one block away, an issue has been reopened because of a recurring problem. We have not caught it and cannot yet explain what is going on. Reopening there is proper. Reopening here is not.