One of my primary functions as a Product Manager is to interact with the Flex community to make sure that the current product is meeting its needs and find out things we can be doing in the future to meet those needs even better. As we’ve moved Flex towards open source we’ve introduced additional infrastructure to help facilitate these kinds of interactions, most importantly the public bugbase. This has been a great mechanism for everyone to let us know what problems they’re facing as well as keep folks informed of what fixes are becoming available. I think it’s worked pretty well, but there are certainly some things that can be improved.
One difficulty for the community is finding a way to let Flex management know that the resolution of a bug is unsatisfactory. E.g., you cannot currently vote on deferred bugs, or if a bug is marked Not a Bug you have little recourse to have the bug re-opened. We do have plans to make sure you can vote on deferred bugs (in fact the implementation is waiting on a staging server, due to release timing we need to wait a little). We also need to implement some queries that will allow us to find bugs that have been commented on after their latest status change, which may indicate the need to revisit.You may recognize why I bring this up, Doug McCune had a pretty strongly-worded criticism on the behavior of the Panel class when its borderStyle was set to a non-default value. I think there are a few reasons why this ended up being frustrating and want to explore that a little.From the Adobe side, our attitude was that we never intended the behavior to work. However, this was not called out in Flex 2, so folks began to take advantage of untested behavior. When we formalized the lack of support in Flex 3 (and removed some hacks that we didn’t like), folks who were using what we considered unsupported behavior ran into issues. We marked the issue as Not a Bug and explained that we didn’t support those additional borderStyles. This may be fair enough if we’re working on something new right? The problem was that regardless of our own internal understanding of whether the behavior was supported, the fact of the matter was that it used to work and therefore reasonable people were relying on the behavior. What we internally might have considered a bug (Panel not rejecting unsupported styles) had become a feature for developers. We made a mistake in failing to recognize that the same bug was being filed multiple times by different people and therefore it was a behavior that multiple folks cared about having back. Folks might have understood (grudgingly) if we had marked the bug as Will Not Fix (because we’re mean, or out of time, or whatever). The Not a Bug status was being taken as an insult. So we needed to reconsider.We are at a point in Flex 3 where we do not consider fixes lightly and generally are now trying to avoid checking in more code. We admittedly only considered evaluating this situation because of the number of folks who seemed to make a statement on it (a bug that doesn’t affect a large number of people has very little chance of being addressed in the 3.0.0 release at this point). We also looked at what the fix would actually be. If we could have put a fix entirely in PanelSkin we probably would have posted the code on Doug’s blog, said “use this new skin” and been done with it. However we found that we did need to make a change in the Panel class which meant that a workaround was much harder for developers. After evaluating the risk of hurting other code we decided to check the fix in. So there you go, PanelSkin will support some of the non-default borderStyles now (and we’ll have to decide if this is now behavior that we need to support forever).So what recourse do you have if you think we’re dropping the ball on other issues? I mentioned a few things above about having voting on deferred issues and better querying that the management team can use to make sure we are paying attention to the community. Additionally when the open source infrastructure is live we will have a development list that can occasionally be used to make sure that the SDK developers are aware of an issue where it seems like it may be lost in the bug system. The final option of course is to contact a Product Manager (like me). My job is about making sure we’re doing the right thing. If you think things are messed up, let’s discuss (mchotin AT adobe DOT com).