Author Archive
Nov
08
Development and Release Processes – Part IV
Posted by: | CommentsSo ... by now most of you have had a chance to interact with Jira, our issues tracking system. Jira is not only used for issues tracking - it is also our project management tool. Everything and anything we are working on or will be working on is in Jira. If there is no Jira entry then it does not exist. Jira entries, in many cases, also contain the specs and if they don't, they will soon. At the end of the day, and for the most part, you all can see what we are working on. We are still working out how to be more communicative, especially for those of you that prefer not to use Jira. But again ... it is all there.
Also by now, you all have seen and experienced the fact that we are doing fast iterations and delivering those to you as soon as they are ready. I am a little frustrated that we are not going faster, but quality is our primary concern. Thus, our speed is dictated by our quality. New features will require longer cycles. Still, we are dying to deliver more and better releases.
When we changed our development process we did it in favor of being more flexible. I wanted to be able to wake up any morning and decide that I wanted to release bug a, b and c, enhancement d, e and feature f, g and h. Since everything is developed in individual branches - well, not exactly, it is more complex than that, but that will be covered in a future post - we have a great deal of flexibility in how we are able to decide what and when to release. Furthermore, since we do continuous integration and nightly builds, we are also continuously testing each build.
Not only do I like this approach, but it has been working well for us - as it did in the past for me as well. And over time, it is going to work even better. There are some inherent drawbacks with this approach, one being that release denominations go out the window. With smaller incremental releases that have bug fixes, enhancements and features, some of the "wow factor" is lost, as well as some clarity in terms of expectations.
The traditional expectations around release denominations is that major "enhancements" to a product - either by adding new features, majorly enhancing or even reworking existing features - are denoted by a change in the version number. An example is vB2 to vB3. Another example is Windows Vista to Windows 7 (not a number change, but a major denomination change.) From a product point of view, these releases should bring a big WOW which is the intention.
Similarly, major revision number changes - i.e.: 4.0 to 4.1 to 4.2, etc. - are expected to represent major milestones in the development of a product's roadmap. And minor revision number changes - i. e.: 4.0.4, 4.0.5, etc. - represent the release of lesser enhancements and bug fixes.
vBulletin followed this model, which is very much attached to a waterfall project management and development methodology. But on a more "agile" form of managing and developing a product roadmap, the model starts to make less sense. Especially if you are eager to release to customers the latest and greatest; and especially if the product showcases some challenges. Even more so since the development process has accelerated getting work done.
So ... what's a customer to expect in this crazy new way vBulletin is being managed?
A major revision number represents the conclusion of a release cycle. In the case of 4.1 for example, 4.0.7, 4.0.8 and 4.0.9, as well as 4.1, all represent the road to 4.1. Thus, 4.1.1, 4.1.2 and so on, concluding with 4.2, are all parts of 4.2. To explain it differently:
1. A major revision is the sum of the previous minor ones
2. We will continue to produce quality releases as often as possible
3. Customers can upgrade whenever they feel comfortable with the progress achieved and available features and enhancements
In re-reading some of the comments from my previous posts, I think (3) is the most problematic of these three points. Customers should not feel pressured to upgrade every time we put out a release.
Let me present the case in a different way: We could produce the same releases as we do now but not make them available at all and, once a quarter, release whatever we accomplished and call it 4.x. This approach does not work at multiple levels. For starters, it shortchanges customers; software will always have bugs and while we strive to be bug-free, that is just not 100% possible and this approach provides continuous relief for old and new bugs.
Second, it removes the ability for customers to decide when to upgrade. In the new way you can upgrade every time or once a quarter or once a year; thus providing more granularity in deciding when to upgrade.
Furthermore, the once-a-quarter approach might work if we wanted to be tight-lipped about what was included; however, while some Jira entries are private and not readable by everybody, we have adopted a policy of transparency.
Still, point (3) remains a concern. The only way (3) will no longer be a concern is if we communicate better what is in each release, including potential areas of risk and shortcomings. The good news: we are already doing this and with each release the quality, not only of the code, but also in the area of communication is improving.
Finally, I would like to take the opportunity that these posts present and thank you all for your feedback. I find your feedback very valuable.
Thank you.
Also by now, you all have seen and experienced the fact that we are doing fast iterations and delivering those to you as soon as they are ready. I am a little frustrated that we are not going faster, but quality is our primary concern. Thus, our speed is dictated by our quality. New features will require longer cycles. Still, we are dying to deliver more and better releases.
When we changed our development process we did it in favor of being more flexible. I wanted to be able to wake up any morning and decide that I wanted to release bug a, b and c, enhancement d, e and feature f, g and h. Since everything is developed in individual branches - well, not exactly, it is more complex than that, but that will be covered in a future post - we have a great deal of flexibility in how we are able to decide what and when to release. Furthermore, since we do continuous integration and nightly builds, we are also continuously testing each build.
Not only do I like this approach, but it has been working well for us - as it did in the past for me as well. And over time, it is going to work even better. There are some inherent drawbacks with this approach, one being that release denominations go out the window. With smaller incremental releases that have bug fixes, enhancements and features, some of the "wow factor" is lost, as well as some clarity in terms of expectations.
The traditional expectations around release denominations is that major "enhancements" to a product - either by adding new features, majorly enhancing or even reworking existing features - are denoted by a change in the version number. An example is vB2 to vB3. Another example is Windows Vista to Windows 7 (not a number change, but a major denomination change.) From a product point of view, these releases should bring a big WOW which is the intention.
Similarly, major revision number changes - i.e.: 4.0 to 4.1 to 4.2, etc. - are expected to represent major milestones in the development of a product's roadmap. And minor revision number changes - i. e.: 4.0.4, 4.0.5, etc. - represent the release of lesser enhancements and bug fixes.
vBulletin followed this model, which is very much attached to a waterfall project management and development methodology. But on a more "agile" form of managing and developing a product roadmap, the model starts to make less sense. Especially if you are eager to release to customers the latest and greatest; and especially if the product showcases some challenges. Even more so since the development process has accelerated getting work done.
So ... what's a customer to expect in this crazy new way vBulletin is being managed?
A major revision number represents the conclusion of a release cycle. In the case of 4.1 for example, 4.0.7, 4.0.8 and 4.0.9, as well as 4.1, all represent the road to 4.1. Thus, 4.1.1, 4.1.2 and so on, concluding with 4.2, are all parts of 4.2. To explain it differently:
1. A major revision is the sum of the previous minor ones
2. We will continue to produce quality releases as often as possible
3. Customers can upgrade whenever they feel comfortable with the progress achieved and available features and enhancements
In re-reading some of the comments from my previous posts, I think (3) is the most problematic of these three points. Customers should not feel pressured to upgrade every time we put out a release.
Let me present the case in a different way: We could produce the same releases as we do now but not make them available at all and, once a quarter, release whatever we accomplished and call it 4.x. This approach does not work at multiple levels. For starters, it shortchanges customers; software will always have bugs and while we strive to be bug-free, that is just not 100% possible and this approach provides continuous relief for old and new bugs.
Second, it removes the ability for customers to decide when to upgrade. In the new way you can upgrade every time or once a quarter or once a year; thus providing more granularity in deciding when to upgrade.
Furthermore, the once-a-quarter approach might work if we wanted to be tight-lipped about what was included; however, while some Jira entries are private and not readable by everybody, we have adopted a policy of transparency.
Still, point (3) remains a concern. The only way (3) will no longer be a concern is if we communicate better what is in each release, including potential areas of risk and shortcomings. The good news: we are already doing this and with each release the quality, not only of the code, but also in the area of communication is improving.
Finally, I would like to take the opportunity that these posts present and thank you all for your feedback. I find your feedback very valuable.
Thank you.
Nov
08
Development and Release Processes – Part IV
Posted by: | CommentsSo ... by now most of you have had a chance to interact with Jira, our issues tracking system. Jira is not only used for issues tracking - it is also our project management tool. Everything and anything we are working on or will be working on is in Jira. If there is no Jira entry then it does not exist. Jira entries, in many cases, also contain the specs and if they don't, they will soon. At the end of the day, and for the most part, you all can see what we are working on. We are still working out how to be more communicative, especially for those of you that prefer not to use Jira. But again ... it is all there.
Also by now, you all have seen and experienced the fact that we are doing fast iterations and delivering those to you as soon as they are ready. I am a little frustrated that we are not going faster, but quality is our primary concern. Thus, our speed is dictated by our quality. New features will require longer cycles. Still, we are dying to deliver more and better releases.
When we changed our development process we did it in favor of being more flexible. I wanted to be able to wake up any morning and decide that I wanted to release bug a, b and c, enhancement d, e and feature f, g and h. Since everything is developed in individual branches - well, not exactly, it is more complex than that, but that will be covered in a future post - we have a great deal of flexibility in how we are able to decide what and when to release. Furthermore, since we do continuous integration and nightly builds, we are also continuously testing each build.
Not only do I like this approach, but it has been working well for us - as it did in the past for me as well. And over time, it is going to work even better. There are some inherent drawbacks with this approach, one being that release denominations go out the window. With smaller incremental releases that have bug fixes, enhancements and features, some of the "wow factor" is lost, as well as some clarity in terms of expectations.
The traditional expectations around release denominations is that major "enhancements" to a product - either by adding new features, majorly enhancing or even reworking existing features - are denoted by a change in the version number. An example is vB2 to vB3. Another example is Windows Vista to Windows 7 (not a number change, but a major denomination change.) From a product point of view, these releases should bring a big WOW which is the intention.
Similarly, major revision number changes - i.e.: 4.0 to 4.1 to 4.2, etc. - are expected to represent major milestones in the development of a product's roadmap. And minor revision number changes - i. e.: 4.0.4, 4.0.5, etc. - represent the release of lesser enhancements and bug fixes.
vBulletin followed this model, which is very much attached to a waterfall project management and development methodology. But on a more "agile" form of managing and developing a product roadmap, the model starts to make less sense. Especially if you are eager to release to customers the latest and greatest; and especially if the product showcases some challenges. Even more so since the development process has accelerated getting work done.
So ... what's a customer to expect in this crazy new way vBulletin is being managed?
A major revision number represents the conclusion of a release cycle. In the case of 4.1 for example, 4.0.7, 4.0.8 and 4.0.9, as well as 4.1, all represent the road to 4.1. Thus, 4.1.1, 4.1.2 and so on, concluding with 4.2, are all parts of 4.2. To explain it differently:
1. A major revision is the sum of the previous minor ones
2. We will continue to produce quality releases as often as possible
3. Customers can upgrade whenever they feel comfortable with the progress achieved and available features and enhancements
In re-reading some of the comments from my previous posts, I think (3) is the most problematic of these three points. Customers should not feel pressured to upgrade every time we put out a release.
Let me present the case in a different way: We could produce the same releases as we do now but not make them available at all and, once a quarter, release whatever we accomplished and call it 4.x. This approach does not work at multiple levels. For starters, it shortchanges customers; software will always have bugs and while we strive to be bug-free, that is just not 100% possible and this approach provides continuous relief for old and new bugs.
Second, it removes the ability for customers to decide when to upgrade. In the new way you can upgrade every time or once a quarter or once a year; thus providing more granularity in deciding when to upgrade.
Furthermore, the once-a-quarter approach might work if we wanted to be tight-lipped about what was included; however, while some Jira entries are private and not readable by everybody, we have adopted a policy of transparency.
Still, point (3) remains a concern. The only way (3) will no longer be a concern is if we communicate better what is in each release, including potential areas of risk and shortcomings. The good news: we are already doing this and with each release the quality, not only of the code, but also in the area of communication is improving.
Finally, I would like to take the opportunity that these posts present and thank you all for your feedback. I find your feedback very valuable.
Thank you.
Also by now, you all have seen and experienced the fact that we are doing fast iterations and delivering those to you as soon as they are ready. I am a little frustrated that we are not going faster, but quality is our primary concern. Thus, our speed is dictated by our quality. New features will require longer cycles. Still, we are dying to deliver more and better releases.
When we changed our development process we did it in favor of being more flexible. I wanted to be able to wake up any morning and decide that I wanted to release bug a, b and c, enhancement d, e and feature f, g and h. Since everything is developed in individual branches - well, not exactly, it is more complex than that, but that will be covered in a future post - we have a great deal of flexibility in how we are able to decide what and when to release. Furthermore, since we do continuous integration and nightly builds, we are also continuously testing each build.
Not only do I like this approach, but it has been working well for us - as it did in the past for me as well. And over time, it is going to work even better. There are some inherent drawbacks with this approach, one being that release denominations go out the window. With smaller incremental releases that have bug fixes, enhancements and features, some of the "wow factor" is lost, as well as some clarity in terms of expectations.
The traditional expectations around release denominations is that major "enhancements" to a product - either by adding new features, majorly enhancing or even reworking existing features - are denoted by a change in the version number. An example is vB2 to vB3. Another example is Windows Vista to Windows 7 (not a number change, but a major denomination change.) From a product point of view, these releases should bring a big WOW which is the intention.
Similarly, major revision number changes - i.e.: 4.0 to 4.1 to 4.2, etc. - are expected to represent major milestones in the development of a product's roadmap. And minor revision number changes - i. e.: 4.0.4, 4.0.5, etc. - represent the release of lesser enhancements and bug fixes.
vBulletin followed this model, which is very much attached to a waterfall project management and development methodology. But on a more "agile" form of managing and developing a product roadmap, the model starts to make less sense. Especially if you are eager to release to customers the latest and greatest; and especially if the product showcases some challenges. Even more so since the development process has accelerated getting work done.
So ... what's a customer to expect in this crazy new way vBulletin is being managed?
A major revision number represents the conclusion of a release cycle. In the case of 4.1 for example, 4.0.7, 4.0.8 and 4.0.9, as well as 4.1, all represent the road to 4.1. Thus, 4.1.1, 4.1.2 and so on, concluding with 4.2, are all parts of 4.2. To explain it differently:
1. A major revision is the sum of the previous minor ones
2. We will continue to produce quality releases as often as possible
3. Customers can upgrade whenever they feel comfortable with the progress achieved and available features and enhancements
In re-reading some of the comments from my previous posts, I think (3) is the most problematic of these three points. Customers should not feel pressured to upgrade every time we put out a release.
Let me present the case in a different way: We could produce the same releases as we do now but not make them available at all and, once a quarter, release whatever we accomplished and call it 4.x. This approach does not work at multiple levels. For starters, it shortchanges customers; software will always have bugs and while we strive to be bug-free, that is just not 100% possible and this approach provides continuous relief for old and new bugs.
Second, it removes the ability for customers to decide when to upgrade. In the new way you can upgrade every time or once a quarter or once a year; thus providing more granularity in deciding when to upgrade.
Furthermore, the once-a-quarter approach might work if we wanted to be tight-lipped about what was included; however, while some Jira entries are private and not readable by everybody, we have adopted a policy of transparency.
Still, point (3) remains a concern. The only way (3) will no longer be a concern is if we communicate better what is in each release, including potential areas of risk and shortcomings. The good news: we are already doing this and with each release the quality, not only of the code, but also in the area of communication is improving.
Finally, I would like to take the opportunity that these posts present and thank you all for your feedback. I find your feedback very valuable.
Thank you.
Sep
27
vBulletin Product Development Process or What’s to Come Part III
Posted by: | CommentsShortly after I started we made changes to the development process (which will be the subject of a future post.) Along with these changes, we also made some initial changes to the QA process. Both of these set of changes were designed to streamline, and make our process more expedient and effective in terms of development and QA. So far these changes seem to be working. The initial changes however, did not include intake and processing of feedback from the community or internal stakeholders, for that matter, on future development.
Another reason for not including feedback into the process was that I wanted to understand the product better and become familiar with the community and the needs of our customers. Alas, finally the time has come to effect more changes. Please note that while we are positive about these changes, they are not set in stone. The process will morph as new challenges arise and the product itself evolves.
The following diagram illustrates the changes we are about me make:
The general idea behind this process is that everything funnels down to a sprint. The crux of the problem we are trying to solve is prioritization. By normalizing features and enhancements across multiple axis, then prioritization as a problem is enormously simplified.
Bugs:
Bug handling will not change. Bugs will continued to be confirmed, scrubbed, and prioritized in the way they have been. Bug prioritization is hard. Bugs affect different boards differently. Thus, each board will think differently about the same bug. We feel that the current handling process is working well. "If it ain't broke, don't fix it." However, overtime, it will evolve.
Community Feedback:
Community feedback is core to making vBulletin better. I feel very strongly about the statement and it saddens me that we don't make better and more effective use of such a valuable resource. That is a problem we are solving with this process change as well.
I want to set the right expectation: while all ideas are good ideas, we will not be able to go after each single one of them. Priority will be given to those ideas that are closely aligned with our overall strategy or have an immediate and direct effect on vBulletin for all stakeholders. Those ideas that we decide not to follow up in the short term will be placed in the "Long Term Backlog" and will be revisited on a regular basis as the product evolves.
I know some of you would like to know more about the strategy and direction of the product. My previous post showcased a mid-term direction of vBulletin. As we can share more information about our plans, we will.
vBulletin Product Team:
We view vBulletin as a very important property and center to Internet Brands. Internally, we have a group of people that breath, eat, sleep, walk vBulletin. These people are not only very passionate about the product, but also very dedicated. They contribute with ideas as well.
Something we wanted was to make sure that no priorities received preferential treatment, that is why any suggestions generated by our customers, or our internal team are evaluated together from a prioritization point of view. Consolidating these suggestions also helps us manage overlapping ideas, or ideas that might potentiate with each other.
As a result of this process change, the product feedback forum will be closed starting on October 11th, and we will use Jira as the intake and processing system for feedback. Jira will allow us all to vote and track New Product and Enhancement requests. It will also facilitate our communication back to you on the status of the request.
We will try to migrate as many requests from the current feedback forum to Jira as possible. Undoubtedly, some will not make it. It will take time, so please be patient. At the same time, you are welcomed to re-enter your feedback in Jira. If you are so inclined and if you could, I would appreciate it you would note in the forum that you already took care of migrating the item so we, on one hand, do not duplicate the effort and are more efficient, and on the other, we do not pollute Jira with duplications.
Thank you, I look forward to your feedback.
Another reason for not including feedback into the process was that I wanted to understand the product better and become familiar with the community and the needs of our customers. Alas, finally the time has come to effect more changes. Please note that while we are positive about these changes, they are not set in stone. The process will morph as new challenges arise and the product itself evolves.
The following diagram illustrates the changes we are about me make:
The general idea behind this process is that everything funnels down to a sprint. The crux of the problem we are trying to solve is prioritization. By normalizing features and enhancements across multiple axis, then prioritization as a problem is enormously simplified.
Bugs:
Bug handling will not change. Bugs will continued to be confirmed, scrubbed, and prioritized in the way they have been. Bug prioritization is hard. Bugs affect different boards differently. Thus, each board will think differently about the same bug. We feel that the current handling process is working well. "If it ain't broke, don't fix it." However, overtime, it will evolve.
Community Feedback:
Community feedback is core to making vBulletin better. I feel very strongly about the statement and it saddens me that we don't make better and more effective use of such a valuable resource. That is a problem we are solving with this process change as well.
I want to set the right expectation: while all ideas are good ideas, we will not be able to go after each single one of them. Priority will be given to those ideas that are closely aligned with our overall strategy or have an immediate and direct effect on vBulletin for all stakeholders. Those ideas that we decide not to follow up in the short term will be placed in the "Long Term Backlog" and will be revisited on a regular basis as the product evolves.
I know some of you would like to know more about the strategy and direction of the product. My previous post showcased a mid-term direction of vBulletin. As we can share more information about our plans, we will.
vBulletin Product Team:
We view vBulletin as a very important property and center to Internet Brands. Internally, we have a group of people that breath, eat, sleep, walk vBulletin. These people are not only very passionate about the product, but also very dedicated. They contribute with ideas as well.
Something we wanted was to make sure that no priorities received preferential treatment, that is why any suggestions generated by our customers, or our internal team are evaluated together from a prioritization point of view. Consolidating these suggestions also helps us manage overlapping ideas, or ideas that might potentiate with each other.
As a result of this process change, the product feedback forum will be closed starting on October 11th, and we will use Jira as the intake and processing system for feedback. Jira will allow us all to vote and track New Product and Enhancement requests. It will also facilitate our communication back to you on the status of the request.
We will try to migrate as many requests from the current feedback forum to Jira as possible. Undoubtedly, some will not make it. It will take time, so please be patient. At the same time, you are welcomed to re-enter your feedback in Jira. If you are so inclined and if you could, I would appreciate it you would note in the forum that you already took care of migrating the item so we, on one hand, do not duplicate the effort and are more efficient, and on the other, we do not pollute Jira with duplications.
Thank you, I look forward to your feedback.
Sep
27
vBulletin Product Development Process or What’s to Come Part III
Posted by: | CommentsShortly after I started we made changes to the development process (which will be the subject of a future post.) Along with these changes, we also made some initial changes to the QA process. Both of these set of changes were designed to streamline, and make our process more expedient and effective in terms of development and QA. So far these changes seem to be working. The initial changes however, did not include intake and processing of feedback from the community or internal stakeholders, for that matter, on future development.
Another reason for not including feedback into the process was that I wanted to understand the product better and become familiar with the community and the needs of our customers. Alas, finally the time has come to effect more changes. Please note that while we are positive about these changes, they are not set in stone. The process will morph as new challenges arise and the product itself evolves.
The following diagram illustrates the changes we are about me make:
The general idea behind this process is that everything funnels down to a sprint. The crux of the problem we are trying to solve is prioritization. By normalizing features and enhancements across multiple axis, then prioritization as a problem is enormously simplified.
Bugs:
Bug handling will not change. Bugs will continued to be confirmed, scrubbed, and prioritized in the way they have been. Bug prioritization is hard. Bugs affect different boards differently. Thus, each board will think differently about the same bug. We feel that the current handling process is working well. "If it ain't broke, don't fix it." However, overtime, it will evolve.
Community Feedback:
Community feedback is core to making vBulletin better. I feel very strongly about the statement and it saddens me that we don't make better and more effective use of such a valuable resource. That is a problem we are solving with this process change as well.
I want to set the right expectation: while all ideas are good ideas, we will not be able to go after each single one of them. Priority will be given to those ideas that are closely aligned with our overall strategy or have an immediate and direct effect on vBulletin for all stakeholders. Those ideas that we decide not to follow up in the short term will be placed in the "Long Term Backlog" and will be revisited on a regular basis as the product evolves.
I know some of you would like to know more about the strategy and direction of the product. My previous post showcased a mid-term direction of vBulletin. As we can share more information about our plans, we will.
vBulletin Product Team:
We view vBulletin as a very important property and center to Internet Brands. Internally, we have a group of people that breath, eat, sleep, walk vBulletin. These people are not only very passionate about the product, but also very dedicated. They contribute with ideas as well.
Something we wanted was to make sure that no priorities received preferential treatment, that is why any suggestions generated by our customers, or our internal team are evaluated together from a prioritization point of view. Consolidating these suggestions also helps us manage overlapping ideas, or ideas that might potentiate with each other.
As a result of this process change, the product feedback forum will be closed starting on October 11th, and we will use Jira as the intake and processing system for feedback. Jira will allow us all to vote and track New Product and Enhancement requests. It will also facilitate our communication back to you on the status of the request.
We will try to migrate as many requests from the current feedback forum to Jira as possible. Undoubtedly, some will not make it. It will take time, so please be patient. At the same time, you are welcomed to re-enter your feedback in Jira. If you are so inclined and if you could, I would appreciate it you would note in the forum that you already took care of migrating the item so we, on one hand, do not duplicate the effort and are more efficient, and on the other, we do not pollute Jira with duplications.
Thank you, I look forward to your feedback.
Another reason for not including feedback into the process was that I wanted to understand the product better and become familiar with the community and the needs of our customers. Alas, finally the time has come to effect more changes. Please note that while we are positive about these changes, they are not set in stone. The process will morph as new challenges arise and the product itself evolves.
The following diagram illustrates the changes we are about me make:
The general idea behind this process is that everything funnels down to a sprint. The crux of the problem we are trying to solve is prioritization. By normalizing features and enhancements across multiple axis, then prioritization as a problem is enormously simplified.
Bugs:
Bug handling will not change. Bugs will continued to be confirmed, scrubbed, and prioritized in the way they have been. Bug prioritization is hard. Bugs affect different boards differently. Thus, each board will think differently about the same bug. We feel that the current handling process is working well. "If it ain't broke, don't fix it." However, overtime, it will evolve.
Community Feedback:
Community feedback is core to making vBulletin better. I feel very strongly about the statement and it saddens me that we don't make better and more effective use of such a valuable resource. That is a problem we are solving with this process change as well.
I want to set the right expectation: while all ideas are good ideas, we will not be able to go after each single one of them. Priority will be given to those ideas that are closely aligned with our overall strategy or have an immediate and direct effect on vBulletin for all stakeholders. Those ideas that we decide not to follow up in the short term will be placed in the "Long Term Backlog" and will be revisited on a regular basis as the product evolves.
I know some of you would like to know more about the strategy and direction of the product. My previous post showcased a mid-term direction of vBulletin. As we can share more information about our plans, we will.
vBulletin Product Team:
We view vBulletin as a very important property and center to Internet Brands. Internally, we have a group of people that breath, eat, sleep, walk vBulletin. These people are not only very passionate about the product, but also very dedicated. They contribute with ideas as well.
Something we wanted was to make sure that no priorities received preferential treatment, that is why any suggestions generated by our customers, or our internal team are evaluated together from a prioritization point of view. Consolidating these suggestions also helps us manage overlapping ideas, or ideas that might potentiate with each other.
As a result of this process change, the product feedback forum will be closed starting on October 11th, and we will use Jira as the intake and processing system for feedback. Jira will allow us all to vote and track New Product and Enhancement requests. It will also facilitate our communication back to you on the status of the request.
We will try to migrate as many requests from the current feedback forum to Jira as possible. Undoubtedly, some will not make it. It will take time, so please be patient. At the same time, you are welcomed to re-enter your feedback in Jira. If you are so inclined and if you could, I would appreciate it you would note in the forum that you already took care of migrating the item so we, on one hand, do not duplicate the effort and are more efficient, and on the other, we do not pollute Jira with duplications.
Thank you, I look forward to your feedback.
Aug
30
What’s To Come For vBulletin – Part II
Posted by: | CommentsAs promised, here is a follow on to my previous post.
In this post I would like to highlight how we are proceeding with the 4.X series and what we are expecting to introduce as part of the series. Please, note that these are not ordered in terms of priorities, but provided as a target list. And of course, as denoted in my previous post, 4.1 will include the top 4 items in this list.
As previously mentioned, we are also working in a re-factoring. The first element to be re-factored is the editor. There will be a common editor across the product. This will improve usability, as users will have a common experience for posting and editing with the added bonus that it also supports WebKit. As a note, not all of our re-factoring efforts will have a visual component, however, with each release we will let you know what was re-factored.
And also as previously mentioned, we will be also working on issues. The target is that each release will have a good mix of features, enhancements and bug fixes. It is very important to us that just as we deal with the challenges; we also further the product and what the product offers.
I do want to make a special note on one of the features included in this list as it pertains to some question from the previous post: Custom Content Type Builder. Some of you asked about the “review” content type. The Custom Content Type Builder will have a few primitives from which we all can build new content types. In theory, and as it has been specified, you should be able to build a review content type with the tool.
Without further ado:
In this post I would like to highlight how we are proceeding with the 4.X series and what we are expecting to introduce as part of the series. Please, note that these are not ordered in terms of priorities, but provided as a target list. And of course, as denoted in my previous post, 4.1 will include the top 4 items in this list.
As previously mentioned, we are also working in a re-factoring. The first element to be re-factored is the editor. There will be a common editor across the product. This will improve usability, as users will have a common experience for posting and editing with the added bonus that it also supports WebKit. As a note, not all of our re-factoring efforts will have a visual component, however, with each release we will let you know what was re-factored.
And also as previously mentioned, we will be also working on issues. The target is that each release will have a good mix of features, enhancements and bug fixes. It is very important to us that just as we deal with the challenges; we also further the product and what the product offers.
I do want to make a special note on one of the features included in this list as it pertains to some question from the previous post: Custom Content Type Builder. Some of you asked about the “review” content type. The Custom Content Type Builder will have a few primitives from which we all can build new content types. In theory, and as it has been specified, you should be able to build a review content type with the tool.
Without further ado:
- Member Profile Customization
- Overhauled StyleVars
- Improved and integrated upgrade Process
- URL Mapping (CMS in root etc.)
- Improved CMS editor
- Google Auth + Twitter
- Mobile Skin (m.vbulletin.com)
- Updated style
- UTF-8 Further Development
- Revised Search
- Activity Stream
- Custom Content Type Builder
- Photo Gallery with Photo Tagging
- Sharing Tools
- Mobile API
- Custom Content Type Builder
- Updated CMS Permissions
- Improved use of Memcached and File Cache
- Member Newsletter Feature (Text + HTML)
- Header Menu Manager Customization (completed spec)
- Unified Moderation and Notifications System
- Unifying widgets and blocks
- Enable Community Moderation (vote up/down content)
- Additional Login Options (Google, Twitter, OpenID, Email Registration, etc)
- Subscription Option: Google Checkout
- Improved Asset Manager
- Updated email management/ and templates to prevent blacklisting
- PostgreSQL support (this will assist and be a part of refactoring our database structure)
- CMS Workflow (change author, draft, approved, unpub date)
- Inline Style/Theme Customization (Inline UI to edit StyleVars)
- Invite Friends Features
- Find Friend Features (via Address Book: Yahoo Mail, Gmail, AOL, etc)
- User can self-delete their profile/account
- Ad Management for Blogs and CMS (and more advanced Forum integration)
- Groups UI/UX
- Calendar UI/UX (also integrate with iCal)
- Expose Developer Documentation (dev.vbulletin.com)
- Official 3rd Party Developer API
- Review content type
- CMS Widget: Tag Cloud
Aug
16
What’s To Come For vBulletin!!
Posted by: | CommentsIt has been about 4 months since I joined IB and became responsible for vBulletin. I have to say that it has been both, exciting and interesting. Exciting because it is great software with incredible opportunities and an even more incredible future. Interesting because there are good set of challenges to overcome at many levels. We are really excited about the recent process changes, as they are beginning to bear some fruits, as well as the current development and the future of the product. At the same time we want to address a number of concerns raised by the community:
In closing, I will make a promise: I will post more information more often.
Thank you!
Fabian Schonholz
- “Internet Brands does not listen to customers.” Of course we do. While I do not spend all my day reading forum posts because I have to look after vBulletin as a whole, I do spend time reading your input and feedback. As a matter of fact, we all do. Developers do, QA does, I do and the rest of management as well. Fair enough, sometimes it may seem that we do not. We do and while not always well represented, we take actions. One example is the fact that we are making our process little by little more transparent, something the community asked for. Hopefully our transition to Jira has assisted with that; furthermore, 4.1 developments consists of items that we see questions asked about the most.
- “People come people go.” A forum member put it in more eloquent words than I can even attempt, however, I will try to paraphrase and expand: in general and somewhat unfortunately, not everyone is going to want to be on the same project forever. People lose interest and move on. That is the norm. There are exceptions just like to any other rule where developers will stay for much longer or much shorter. Is there risk with people moving on? Absolutely, but well established companies like IB mitigate that risk by cross-training personnel. On a personal level, we miss people we work with, especially when they are nice folks to work with and you have established a relationship; in my current tenure I have already developed some of those relationships; as a mature manager, I make sure that I take the fact of people moving on into consideration as I plot my course.
- “Fast release cycles.” Our intent is to not only accelerate release cycles but also make them more predictable and more transparent. It will take a while to develop the cadence we want, but it will get done in due course as the new process matures and evolves. While you can, you do not need to upgrade with every release, and with added documentation you will be able to decide if and when to upgrade. So, why accelerate then? Three reasons: improve quality by having well defined and scoped releases, provide faster bug fixes and finally, evolve the product faster. We are the leaders in the space and we want to continue to stretch our lead even further.
- I admit it, “Jira is a mess.” We are working on cleaning it up, but we need your help. Currently we are going bug by bug and deciding in which bucket each bug belongs. It is going too slow for our liking. The QA team however, is making some real good progress. It may come as a last resort that we decide to close bugs based on some pattern - for example: anything before March. Now, taking that approach is not ideal because many valid and critical bugs will be artificially closed. We will need your help in bringing back some of those bugs.
- “Where’s the road-map.” We can understand people wanting to know the roadmap. Knowing the road-map will add the predictability we all want. I wish I could be VERY precise but I cannot as I do not want to make promises that we may not be able to fully deliver. I am a stickler for keeping up promises. But ... Here is a little preview:
• We just released 4.0.6 and we have begun work on 4.1. Will there be a 4.0.7? Maybe. The changes we made to the development process allow us to move code from one track to a different one. We might package a 4.0.7 release based on how 4.1 progresses.
• 4.1 is coming mid September to mid October. It will contain as cornerstones an improved and re-factored stylevar system with an easier way to customize your board and will also make it easier to upgrade without breaking customized styles. Additionally, we will release a profile customization tool. And finally, a means to better configure your boards and the entry points to it. And no, we are not forgetting bug fixes, including fixes outside of the described features.
• There will be a series of maintenance releases for the 4.1 series. We want these to come fast. They will include bugs at the center of each release, but each will also contain enhancements and features.
• 4.2 is currently intended – but not promised - for mid December to mid January. We have a few features we want to add for that release, however, we are still working on it. And again, it will contain more bug fixes.
For the critics: it is a short term road-map. We have lots of big ideas for upcoming releases, but we are also going to polish the core pieces we already have.
- “What about re-factoring?” YES, YES, YES!!!! We are re-factoring. We are taking an incremental approach to it and in most releases you will see - or not - small parts of the re-factoring making it into the code and release. At some point we will make a big push to finish it up. Unfortunately during that last push we will not have a release. We intend to minimize the time without a release. Furthermore, part of the re-factoring will include the ability to support other databases besides MySQL.
- “What about vBulletin 5?” vBulletin 5 is underway. I wish I could disclose what it contains because I think it will be very cool and ground breaking. But I can not share with all of you yet what vB5 is. I am so tempted!! Yes ..you can call me a tease ;)
In closing, I will make a promise: I will post more information more often.
Thank you!
Fabian Schonholz
Apr
14
Hello to the vBulletin community
Posted by: | CommentsI wanted to take some time and introduce myself: my name is Fabian Schonholz and I recently started at Internet Brands as the Vice President of Technology responsible for vBulletin. My background in software development started a long time ago, but of note, the last 15 years of my career have been dedicated to Enterprise Grade web based products, with the last 10 years at the technology helm of several start-ups, developing very scalable products and pushing the envelope at the technology stack and architecture levels.
It is exciting to be here.
I used vBulletin as a forum package back in 2004/2005. Anytime somebody has asked me for a forum product recommendation, I would recommend vBulletin. I always thought of it as a fantastic product and as luck would have it, now I am responsible for it – how cool is that!!
Since the time I first used vBulletin, the package has evolved dramatically and continues to evolve. I am in the process of getting an understanding around the list of defects (bugs) and features so I can plot a course of action and attack the list. Both are important, a good and solid software and keeping pace with market and customer needs. I am committed to delivering both.
In the last two weeks, I have been talking to the development team behind vBulletin and management, and have spent time reading the forums. I have to say that I am encouraged by the passion for the product; both, by the community and by the Internet Brands team. It is a great feeling to come to work everyday and share my time with people with such great passion for such a product.
I appreciate all the feedback and comments you are able to provide on the product on a regular basis as it enables us to make further improvements. I already started reading through them and hope to read more, but I will probably leave the communication and posting up to the support team and Adrian, as I am focusing my time on improving the product. If you have a question specifically for me, you are welcome to pass it through Adrian or the support staff.
I look forward to our working together to make vBulletin the continuing leader in the market.
Thank you.
It is exciting to be here.
I used vBulletin as a forum package back in 2004/2005. Anytime somebody has asked me for a forum product recommendation, I would recommend vBulletin. I always thought of it as a fantastic product and as luck would have it, now I am responsible for it – how cool is that!!
Since the time I first used vBulletin, the package has evolved dramatically and continues to evolve. I am in the process of getting an understanding around the list of defects (bugs) and features so I can plot a course of action and attack the list. Both are important, a good and solid software and keeping pace with market and customer needs. I am committed to delivering both.
In the last two weeks, I have been talking to the development team behind vBulletin and management, and have spent time reading the forums. I have to say that I am encouraged by the passion for the product; both, by the community and by the Internet Brands team. It is a great feeling to come to work everyday and share my time with people with such great passion for such a product.
I appreciate all the feedback and comments you are able to provide on the product on a regular basis as it enables us to make further improvements. I already started reading through them and hope to read more, but I will probably leave the communication and posting up to the support team and Adrian, as I am focusing my time on improving the product. If you have a question specifically for me, you are welcome to pass it through Adrian or the support staff.
I look forward to our working together to make vBulletin the continuing leader in the market.
Thank you.
