Bugs and Suggestions

21-Dec-09 23:10

FAQ says:
What is the purpose of the 'Minor Changes' checkbox on the post page?
This option is only visible when updating an existing Quick Answers entry. By checking it you are marking the current edit as consisting of only cosmetic changes such as formatting, spelling or grammar. You would not check this if you are adding/removing content or reworking the post. Code Project uses this flag to filter what is sent out on RSS subscriptions to these entries.

First of all, I have to apologize about not using it the first time, I just forgot it. And that's actually the point.

I think it could be better using it just on the other way. I mean... Minor changes could be the default value of an edit. Most of the times, the edits are because of Typos, Format changes and so on. EDIT: At least when the edited message is your own message.

Relevant content changes, corrections or additions are less usual than the others and then, in my opinion, is when the check-box should be used.

Many people are not going to read the FAQ, and even people that have read the FAQs and are "legal" users (respecting the rules and the correct way of doing things) may forget to activate the Tag when doing a fast edit.

Regards.
--------
M.D.V. Wink | ;)

If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.

modified on Tuesday, December 22, 2009 10:29 AM

Thiru Thirunavukarasu22-Dec-09 5:20

22-Dec-09 5:20

Thanks for the comments Nelek. But I'm afraid checking the 'Minor Change' option by default would inadvertently mark "real" changes as minor. As you correctly noted most people don't read the FAQ and won't bother adjusting this option. Though I'm sure many minor changes will be marked as non-minor I think that's better than having non-minor changes marked as minor..

Luc Pattyn22-Dec-09 6:47

22-Dec-09 6:47

I do not know what the relevance of "minor change" is, however offering a default will always result in a lot of false attributes. So I suggest:
1. you compare the item before and after the change; if size was altered by more than 10%, or more than 20% of the paragraphs were altered, it could be called a major change.
2. and when in doubt, you explicitly ask the author after he saved the content, i.e. make it sequential.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

Thiru Thirunavukarasu22-Dec-09 7:04

22-Dec-09 7:04

Luc Pattyn wrote:
I do not know what the relevance of "minor change" is

When we have subscriptions in place (or when sending out emails) we'll hide minor change edits. We also hide them on the version history page.--In both cases to reduce noise. The value of this considering the complexity it adds is debatable. I first came across this feature in DokuWiki and thought it'd be useful here as well. But I only ever used that for myself - not with millions of other people. Practice may very well show us otherwise. Sniff | :^)

It'd definitely be good to add some smarts around detecting minor changes programmatically. I'm not sure if detecting the percentage changed would do it. And asking the user when saving might be too much of a burden? I personally wouldn't mind being asked this question but I wonder if other members would complain. Maybe if we brought up a pretty jQuery dialog it'd help things..

Anyway, thanks for the thoughts. We'll definitely need to re-evaluate how this works.

Luc Pattyn22-Dec-09 7:41

22-Dec-09 7:41

I think I understand now. As its main purpose is notification filtering, this would be my way of thinking:

1. have an automatic "change" evaluation, resulting in a number (say a scale of 0 to 2; i.e. 0 = any change; 1 = size changed by >=10% or >=20% of paragraphs altered; 2 = size changed by >=20% or >=40% of paragraphs altered)
2. have some way for the author/editor to bump the value upwards (add 0/1/2 saturating on maxvalue of course)
3. give the subscriber the choice to what change level he subscribes.

How this would be used by writers:
- a formatting/typo change gets a low value and does not deserve a bump, so it would result in 0 or 1 automatically; no worries.
- a content change (say adding an example) would result in 1 or 2 automatically; no worries.
- fixing an error (say adding "not" to a sentence) would result in an automatic 0, but deserve a full bump since everyone probably wants to know it. This is the only case requiring human intervention.

readers subscribe to change level according to relevance
- the original author, an editor, or a user would want it all (subscribe at 0)
- a casual reader may want notifications only for larger changes

Net result: the author/editor doesn't do much, it is the subscriber who decides what he will get notified about.

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

modified on Tuesday, December 22, 2009 2:05 PM

Thiru Thirunavukarasu22-Dec-09 10:48

22-Dec-09 10:48

Interesting. We have a task to automate Minor Change some how and I'll add your suggestions to the notes.

However I disagree that the only time we need human intervention is at 0. An editor may change significant parts of the post for readability. I think this should be marked as minor.

How about just requiring the editor make an explicit choice on whether their edit is minor or not? If they forget to make a choice we reveal (hidden by default) a detailed explanation on what Minor Change is all about.

Luc Pattyn22-Dec-09 11:05

22-Dec-09 11:05

Thiru Thirunavukarasu wrote:
However I disagree that the only time we need human intervention is at 0. An editor may change significant parts of the post for readability. I think this should be marked as minor.

I disagree, for several reasons:
1. An editor can make mistakes, if he changes a lot and I have visited before, I'll want and read it again, even if he intended not to change the meaning.
2. I will skip badly formatted questions (e.g. code without PRE tags), and may want notification when the formatting gets improved, while not being interested in minor changes.

Anyway, my suggestion remains: automatic evaluation, and the default is to accept that (so bump defaults to zero). If you think you must support a negative bump, by all means give it a try (but I wouldn't).

Thiru Thirunavukarasu wrote:
How about just requiring the editor make an explicit choice on whether their edit is minor or not? If they forget to make a choice we reveal (hidden by default) a detailed explanation on what Minor Change is all about.
Quote Selected Text

IMO the question, if asked at all, should be asked after the edit session. I don't always know beforehand how big my changes/additions will be. Here is an idea, if you don't like the bump idea:

when editing, only provide a "preview" and a "cancel" button, nothing else.
upon PREVIEW, show the preview page, which has four buttons: "back to editor", "publish as minor change", "publish as major change", "cancel". And make one of the publish buttons much bigger than the other, which one depends on the automatic change evaluation. (Do NOT let the buttons switch places!!!)

Advantages: author/editor is forced to preview and to think about minor/major change.
One can do more than leading the horse. Laugh | :laugh:

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

Thiru Thirunavukarasu22-Dec-09 11:35

22-Dec-09 11:35

Luc Pattyn wrote:
1. An editor can make mistakes, if he changes a lot and I have visited before, I'll want and read it again, even if he intended not to change the meaning.
2. I will skip badly formatted questions (e.g. code without PRE tags), and may want notification when the formatting gets improved, while not being interested in minor changes.

Excellent points! I didn't think of it that way; you've convinced me. Smile | :)

We'll try your original suggestions (when we get to this task that is) and see how that works out. You're latter options are great as well. We can always make changes later on if there's some unforeseen issues with the first approach.

Thanks!

Luc Pattyn22-Dec-09 11:45

22-Dec-09 11:45

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

Nelek22-Dec-09 22:27

22-Dec-09 22:27

Nice points.

I wouldn't mind to be forced to preview and choose before getting my edit posted.

Regards.
--------
M.D.V. Wink | ;)

Nelek22-Dec-09 8:20

22-Dec-09 8:20

People that do "real" changes are, most of the times, users with advanced knowledge and usual users/readers/contributors of this site. So these people know what to do and how to do it. So when one of that users do a major change, they will check / uncheck the tag, because it is good for their reputation points and so on (if I understood right the FAQs). I guess not so many will forget it.

Taking a look into your answer below:
"When we have subscriptions in place (or when sending out emails) we'll hide minor change edits. We also hide them on the version history page.--In both cases to reduce noise."

Having minor changes as default will automatically help you with this purpose.

When I ask a question, I keep track on the thread/andwers and so on during a few days (until I consider that probably no more answers will come). If "standard" users don't keep an eye on his own questions, is not your problem, it is his/her problem, but it will help you with less data to handle for your history and feedbacks.

Anyways... it was just an opinion.

Regards.
--------
M.D.V. Wink | ;)

Thiru Thirunavukarasu22-Dec-09 11:15

22-Dec-09 11:15

Thanks for your thoughts on this but I have to be honest. I don't think setting the default to Minor Change is the way to go. We either need some very clever way to determine this programmatically or have the editor make an explicit choice. Sniff | :^)

Nelek22-Dec-09 22:29

22-Dec-09 22:29

You are right. I just thought from the point of view of an average user. I didn't have the perspective of expert users. I think luc's ideas are much better (if not the best aproach) to make it.

Regards.
--------
M.D.V. Wink | ;)

Thiru Thirunavukarasu23-Dec-09 4:33

23-Dec-09 4:33

Great! Glad we're all agreed Wink | ;)

About voting system

Nelek21-Dec-09 22:38

21-Dec-09 22:38

Hi,

I have had for a time the issue that I can not vote messages in forums when I am at work, because of proxy/firewall of the firm. But in the new "Quick Answers" I haven't got this problem.

I am just curious, why is that? what is different?

Regards.
--------
M.D.V. Wink | ;)

Re: About voting system

Rajesh R Subramanian21-Dec-09 23:01

Rajesh R Subramanian

21-Dec-09 23:01

With quick answers, each query works like if it were an article. With our regular message boards, you'll be voting on a post. (I may be wrong though...)

“Follow your bliss.” – Joseph Campbell

Re: About voting system

Chris Maunder22-Dec-09 5:19

Chris Maunder

22-Dec-09 5:19

Are you seeing an error when you try to vote? (either javascript error or site error?)

cheers,
Chris Maunder

The Code Project Co-founder
Microsoft C++ MVP

Re: About voting system

Nelek22-Dec-09 8:24