Feedback on developer feedback (aka ideas and issue reports) is important

Giving feedback to developers who actively contribute to the improvement of the platform by providing ideas (suggestions for improvements) and issue reports (bug reports) is very important.
Most developers who do not get any feedback at all or only meaningless statements will end up by not providing feedback anymore.
A no-feedback policy breaks the loop that keeps everyone motivated.

This example shall serve as an illustration:
Support for ISO 8601 date format in import and data entry

Not natively supporting the ISO date format in a database in the year 2023 is a clear miss. Providing no feedback at all to the OP of the idea and the community for a full 4 years is an even larger miss.

Claris asked for feedback from developers and it was said that feedback on ideas and better feedback on issues is very important. Many developers are waiting for just that.

1 Like

What kind of feedback would you like to see on old product ideas like the one you linked? It has a lot of thumbs up, and I can't think what else there is to say.

At that point it seems the ball is in Claris's court to implement or not.

I would at least expect to be informed for what good reason the ISO format was skipped.

1 Like

@jwilling I believe Torsten is talking about follow-ups from Claris.

We all have our own wishes for feature requests and Torsten was giving one example out of the many feature ideas (feature requests) that community members have submitted over the years.

I tend to be a bit more nuanced in how I would qualify a single feature, so I won't comment about it being a clear miss or being skipped and if a reason qualifies as good or not, but I think Torsten is voicing a concern that many have where the suggestion box Claris has in place for product ideas feels too much like a black hole from the communication angle of things (suggestions go in, nothing comes out).

It used to be that product suggestions were simply a web form on the Claris site and community members had no visibility about each other's ideas. I assume this meant the community was loosing (because we could not get inspiration from other people's suggestions) and Claris was getting many duplicate requests. Over time, the request count and the lack of updates from Claris made it next to impossible for someone submitting a new idea to know if it replicates an existing one or not, so we are back to square one on that aspect. All in all, I like that we now have visibility about other people's ideas, and I believe the fact Claris has limited resources and cannot possibly implement every one of them would be easier for us to accept if there were more updates from Claris making their way back to the community.

Something else that can be difficult to accept is that the "upvote" system can make it feel to community members that top voted ideas should be implemented in the product (almost in a democratic vote fashion, or as a very high signal of what to prioritize). It seems the upvotes are simply one of the signals Claris may take into consideration, but we can clearly see feature ideas with solid support in the community that are yet to make it into the product, leading a good number of community members those features will never make it into the product.

It gives the whole thing look almost as a lottery, because we do not have the required information to decipher why Claris prioritized X over Y, even less predict that process and it's outcome.

For the rare instances where I saw one of my suggestions implemented, I was very thankful, not even because it felt like the product now had one more piece of the puzzle, but rather because it felt like despite the appearances, it remained possible for some things to get through and come out the other side and that meant someone is listening, at least sometimes, and I felt like I could get heard.

We should not forget that in our community, many will go through the same process, but will never get to feel like someone is listening, and that is something that is damaging the relationship. We can hope for improvement, but it remains in itself something difficult to address.

4 Likes

I misunderstood. I fully agree it would be nice to get more active feedback from Claris on issues so they didn't feel like a graveyard as often.

2 Likes

I totally agree with you, there is no good reason to skip ISO8601. Maybe integration of the total standard would be a bit much, but they could have at least made possible to import the YYYY-MM-DD in dates and timestamps.

There is however a bit of light from the horizon: since version 19.6 you can specify the dateformats for GET and FIND in the DataApi. It is NOT in the documentation (yet).
Simply add &dateformats=2 at the end of the URL for ISO8601 (1 for the file's locale and 0 for US format). You can't change the format for the CRU commands :frowning:

A problem for me was that Claris had forgotten to put this possibility into the Execute Data API scriptstep. So I created a bug-report and they corrected the problem with the release of fm 20(23)!

Just add a dateformats object in the root of the query:
{"action":"read","layouts":"calendar_items","dateformats":2,"version":"vLatest"}

Again, there is no documentation yet, but it works flawless

2 Likes

Yes, that’s great and it is unfortunate that we cannot even ask for it being documented. It is a good example of how better feedback would benefit to everyone.