HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


ocProducts feedback procedures

Written by Chris Graham and Allen Ellis, ocProducts
This article exists to address questions with how ocProducts handles feedback. There has been some confusion as to why we don't answer our user's feedback often, so we would like to take this time to clearly explain the reasons behind our policies, and to show that we take feedback very seriously.

How we respond to questions

Feedback is among the most important aspects of developing ocPortal. Our users are often able to show us ideas from new angles, which play a big role in ocPortal's future. Unfortunately, it is not possible for us to comment on whether or not any certain feature will be developed. This is why you'll see us use a form letter such as:

Thank you for taking the time to share your feedback with us. We will look into the possibility of implementing your idea but we are not able to comment on whether or not we will include it in the future.

The reason we can't comment on user feedback is because whether we answer 'yes' or 'no' we end up in a difficult situation:

If we declare 'yes' to a suggestion immediately:


  • Our plans might change for a good reason that we hadn't foreseen – meaning it wouldn't be included after all. This can happen if the design process reveals a big problem with the idea. This is often the case, even for our team's own ideas. This is a big problem if any of our users build their plans around our premature announcement.

  • Even if we do develop the feature it might take longer than people were expecting, and this not only rushes us into making releases too early, but our users can develop a dependency on us that is unhealthy for not just the development process, but the health of the user's business/organisation.


If we declare 'no' to a suggestion immediately:

The problem with this is that it almost always causes arguments – which of course we wish to avoid.

The reason that arguments are so counter productive lies in the fact that we, and virtually all other companies, are not in a position where we can accept every suggestion from every user. We have to make wide and complex decisions, based on information most people never see, and based on our years of engineering and design experience. This is far more complex than most people realise.

ocPortal extendibility


It is true that we are often not able to implement a particular feature for a variety of concerns we have about its side-effects. But there are situations where an individual might not be concerned with those particular side effects and still desires the change. In light of this, we've gone to huge lengths to make sure that other people are able to do this if they desire. We completely appreciate that it is beyond the knowledge of most users to do this themselves, but we have kept this avenue open as a point of principle.

Some users are in the position to be able to pay others to make changes on their behalf, and other people are not. Unfortunately this inevitable issue exists because we cannot possibly cater for everyone's website ideas for free. It is typical for a website with even moderate sophistication to cost over $40,000 (approximately 30,000 GBP) if developed from scratch using traditional methods. ocPortal provides an incredible cost saving compared to that rate – we make features to meet common needs, and the cost of meeting those common needs don't have to get paid by everybody any longer. But like everything in life, there is still a cost in time or service-payments if some uncommon ideas are to be realised; the more the ideas vary from what ocPortal provides already, and the more complex the ideas are, the more time-consuming/expensive they would be to realise.

Hopefully this has given you a bit of perspective as to why we don't answer feedback right off the bat. If you're curious as to what an actual feature adding process is like, go ahead and read our sample feature implementation article. It walks you through all of the little details that accompany planning a feature, and shows the reasons why we don't admit every single feature that's proposed (even if a lot of them are good ones).
In the spirit of Open Source we also have posted all our teams own ideas on the public feature tracker and it is from here that we manage the development process. You can see from the tags we choose how we take risk analysis very seriously – there are a lot of features on there that have tags that imply we cannot make the change outside a major new version, which is not surprising given the tracker is showing those features we haven't been able to implement yet. Everything ocProducts has posted on there is planned in some sense, but there is also no roadmap, so it could be countless years along the line (or even never) before we are able to allocate the development resources needed for any particular feature and/or get past detailed risks by scheduling the change into a major new version. We do make it easy for users to sponsor features though so that things can be slipstreamed to the users that need them early.

Priorities

The prioritisation of ocPortal features is not simple. Each major ocPortal release usually hosts a wide range of new features, but also concentrates development on one particular overall objective. Typically we do this because we want to do something big and the only way to do it is to make a 'release mission' (OCF, for example).

We (at the time of writing) have almost 200 issues for ocPortal on the tracker that we had and decided we intended to implement things for, but haven't yet completed. This probably translates into around 500 new planned features.
In the fortnight before we implemented about 60 small new features.
Therefore we have a great deal planned, and have achieved a great deal, and much of it we consider very worthwhile. Different features are most useful to different people – and much of our prioritisation involves us thinking what is "most important for the most people".
In the past we have implemented completely new features that nobody has ever suggested before, and people have loved them. "Redirect pages" is one example, that user's now use to solve a lot of issues. Therefore our priorities are not based only on requests, but are filtered by our best judgment (taking all our information and insight into account).

In patch releases we typically only fix bugs. However on some occasion we do fix oversights which we consider to:
  • be at least moderately annoying
  • be easy to fix
  • introduce low risk of future bugs
  • not introduce incompatibilities

Most features introduce risk in a number of areas, and all features are subject to some kind of prioritisation. For example:
  • there is quite a large risk if we change the database structure, due to complexities of upgrading.
  • there is large incompatibility if we add to the CSS, because it means people's customised themes get busted.
It is best that risk and incompatibility is managed in bulk, in major releases.



Have a feature idea? Hop on over to tracker and share it!

Best regards,

The ocPortal team