|
I thought you'd mentioned possibly parsing your IIS log file collection to extract that data.
Since you haven't, what historical data did you add to reputation in the most recent update?
3x12=36
2x12=24
1x12=12
0x12=18
|
|
|
|
|
I've noticed - I seem to have gained quite a lot of reputation. Out of interest, my Organiser rank is 180, which puts me at Bronze. What are the criteria for these ranks?
[edit] While I think about it, would it be possible to filter out ? I've noticed that one or two people work around the inability of the system to reproduce the spacing of their code outside of pre blocks, by using that HTML code. It's a nightmare to edit out.
modified on Wednesday, December 23, 2009 12:16 PM
|
|
|
|
|
The Rep Page[^] shows the levels.
We're still tweaking, though.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
Ah, I missed that; thanks.
|
|
|
|
|
Where's the breakdown shown?
3x12=36
2x12=24
1x12=12
0x12=18
|
|
|
|
|
Breakdown of your rep graph? That's coming soon. If you yell at Thiru and guilt him a little, maybe today or tomorrow. Otherwise, after Christmas.
We...need...sleep!
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
If you're not providing the information, then how did 0x3c0 find out his organizer score was 180/bronze?
3x12=36
2x12=24
1x12=12
0x12=18
|
|
|
|
|
|
For every article, the Share link should also include Twitter. You have Facebook, del.icio.us and tons of other stuff but no twitter!!!
Regards
Partha Mandayam
Software Developer
CardinalCommerce
http://partha.tripod.com
http://weblogs.asp.net/pmandayam
|
|
|
|
|
It hurts me just thinking about Twitter.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
Time to unleash the attack hamsters so they can gnaw his[^] nuts off.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
gnawing complete
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
Excellent.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
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. 
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
|
|
|
|
|
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..
|
|
|
|
|
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.
|
|
|
|
|
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. 
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.
|
|
|
|
|
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.
modified on Tuesday, December 22, 2009 2:05 PM
|
|
|
|
|
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.
|
|
|
|
|
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. 
|
|
|
|
|
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.
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!
|
|
|
|
|
NP
|
|
|
|
|
Nice points.
I wouldn't mind to be forced to preview and choose before getting my edit posted.
Regards.
--------
M.D.V.
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.
|
|
|
|
|
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.
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.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
