Attempt at more detailed changelogs for desktop snapshots
Thursday, 23. April 2009, 11:05:54
For the upcoming desktop snapshot, we are trying out a more detailed changelog than we usually do. I looked through the internal changelogs since the previous snapshot, and tried to include as many changes as possible, and I have included the bug ID whenever possible.
One problem with this is "information overload", so we will have to figure out a way to organize it properly, and highlight things that may be important to most people, or that we want more focus on for that build.
Another problem is that the raw changelogs contain a lot of sensitive information, things that aren't even relevant to public builds, and so on. It takes some time to weed out these things.
But if this works out, we may be able to get a better process in place for more detailed changelogs in future snapshots.
One problem with this is "information overload", so we will have to figure out a way to organize it properly, and highlight things that may be important to most people, or that we want more focus on for that build.
Another problem is that the raw changelogs contain a lot of sensitive information, things that aren't even relevant to public builds, and so on. It takes some time to weed out these things.
But if this works out, we may be able to get a better process in place for more detailed changelogs in future snapshots.
WIDGETIZE
Remco Lanting # 23. April 2009, 11:11
Galileo # 23. April 2009, 11:28
zoquete # 23. April 2009, 11:40
I can not believe it.
Phred # 23. April 2009, 11:43
Originally posted by haavard:
Perhaps it would be information overload for my mom or dad but the majority of people frequenting the desktopteam blog are not normal people. Most of the inviduals seem to be rather capable and technical people. Perhaps you have not seen all the people (including myself) complaining about the one-wayness of the communication between Opera and ourselves? I think you would find yourself hard pressed to information overload those dedicated to the testing process. I actually double dog dare you to information overload us! I bet you can't do it!Anonymous # 23. April 2009, 11:44
"Most of the inviduals seem to be rather capable and technical people"
:lol:
Joonas Lehtolahti # 23. April 2009, 11:47
Ravindran Navaneethan # 23. April 2009, 11:53
Tamil # 23. April 2009, 12:04
Haavard # 23. April 2009, 12:17
Zotlan # 23. April 2009, 12:51
Rijk # 23. April 2009, 15:20
Right
Doesn't mean they are capable of sifting the (for them) useful information from a large pile, which is why it will be a challenge for Haavard to present it in a useful way. Think of all the people who don't even read the warnings and complain about known issues in the comments
BTW, I'm sure the bug numbers that will get included will often be not the ones you know about. When things move to the Core project, they get a new number, many reported bugs are duplicates where the report that gets fixed is one that was reported internally earlier, etc. But given his sources and the format Haavard is working on, it is just as easy to leave those numbers in anyway.
Phred # 23. April 2009, 16:03
Originally posted by Rijk:
Based on the number of unique users I see in the blog comments, the number of people who don't/can't read are negligible. Don't (always) penalize the intelligent to aid the ignorant. And because you will probably ask/think it: Yes, i consider withholding information a penalty.Keep in mind that I greatly appreciate what you are doing and the strides you are making. However I have an end goal that the lazy/ignorant people are now impeding which is an unfortunate roadblock.
FataL # 23. April 2009, 16:59
You can use a standard list style.
Most prominent changes put on top of the list and make them bold. If some changes are dangerous color them in red also.
Anonymous # 23. April 2009, 21:28
The more info the better. BUG ID references are good, because as a submitter, I can see when you have fixed it, and confirm the fix is good.
Looking forward to a new 10. alpha and lots of info to read :-)
Bill P # 23. April 2009, 22:02
Kyle Baker # 23. April 2009, 22:33
Thanks for the update!
Kamalesh # 24. April 2009, 03:17
As many have mentioned already, info overload needn't be a concern. Some of us crave more details, so we can better focus useful feedback for you.
To simplify it, I may suggest you consider organizing the changelog by component or maybe by user sophistication (i.e., intermediate technical, advanced technical, developer). All the v10-alpha testers like to focus on their favorite parts of Opera or browser components, I think, so this may let them realize and test the changes they appreciate most, etc...
Keep up the good work!
Kyle Baker # 24. April 2009, 09:36
I agree with sophistication levels for organizing data, but honestly...I love Trillian Astra's method of posting the changelog. They always post it as an attached text file that doesn't waste space and has all the information needed.
I feel like that would be the best of both worlds, because there is no need to organize since those who care to check can glance through what they wish, but those who could care less can ignore the changelog link!
Example:
http://blog.ceruleanstudios.com/?p=434
http://blog.ceruleanstudios.com/wp-content/uploads/2009/04/cl-04-21-2009.txt
Anonymous # 24. April 2009, 14:20
no new build today :(
zoquete # 24. April 2009, 14:27
Haavard # 24. April 2009, 14:53
Darko Pantić # 24. April 2009, 16:51
Ben Tudball # 11. May 2009, 12:15
A suggested improvement would be to update the Known Issues with some of the common/broad problems found and reported in the comments. This would at least provide some small interaction between the Desktop Team and testing users. And maybe someone on the Desktop Team could add a short comment to notify that a reported problem has been added to the Known Issues.