|
I no longer have any use for my account.
Can you delete it please.
Cheers
|
|
|
|
|
You can do that yourself. Here's how[^].
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
In my team we are struggling with code documentation.
Most of the examples we wish to share apply to our development stack.
With our class libraries, html components, inhertance
It would be great if we could create a private site on the code project platform to share our code and examples.
|
|
|
|
|
How much were you proposing to pay Chris et al for providing you with hardware, software and bandwidth for your private site? After all, I assume your company doesn't give your work away for free.
Why not sign up for a GitHub[^] or Visual Studio Team Services![^] account, and use that? Or use one of the many available Wiki products[^] to create your own site?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Well I think it would be valuable solution. So yes we would be willing to pay for this.
I'm sure some monthly fee would be acceptable.
We're paying fees for Azure services as well
|
|
|
|
|
Use Team Foundation for that. It supports SDLC and provides source control as well as messaging.
I don't think using CP as team support is a good idea because the site changes with more frequency than you'd be comfortable with. It also shouldn't be hard to stand up a web server with some sort of blogging/dev support.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Message Removed
modified 5-Oct-16 9:13am.
|
|
|
|
|
Seems that the interpretation if an article/tip/post is new or updated is a little bit off.
For example the tip TrimChar to Remove Desired Character[^] was posted on Monday 26th of September and it wasn't included in newsletter Newsletter - 26 Sep 2016[^]. In this weeks newsletter Newsletter - 03 Oct 2016[^] the tip is in section "Tips and Tricks updated".
Few questions:
- Could the reason be for example that the post was made between gathering the newsletter material and publishing the newsletter?
- Also, if the tip wouldn't have been updated during the week, could it be that it wouldn't be included in the newsletter at all, not as new nor updated.
|
|
|
|
|
There's a quirk to the way things appear in the newsletter. It's not done by creation date, it's done by first posted date (so the day it goes live). So since your article went live Friday, it is in this week's newsletter.
Thanks,
Sean Ewington
CodeProject
|
|
|
|
|
Why do you say it went live on Friday? As far as I recall I both wrote it on Monday 26th and it was immediately published. The same is shown in version history... 
I understand that it wasn't included in last weeks newsletter, but shouldn't it be in this weeks newsletter inside section "New Tips and Tricks added". I mean even though it has been updated during the week, the first operation between the newsletters was the initial publish. So in my understanding the oldest state for a post between newsletters should define the category where it belongs to.
Not a big deal but current situation feels a bit funny 
|
|
|
|
|
Huh look at that, Monday. Every time I read the revisions list I read it wrong.
It is in this week's newsletter? Was it not in yours?
Thanks,
Sean Ewington
CodeProject
|
|
|
|
|
Yes, it was in this weeks newsletter, but the point is that even though it was initially published last week, it was in section "Tips and Tricks updated", I would have thought it would have appeared in "New tips and tricks"
|
|
|
|
|
OK I think I finally get it. The newsletter isn't smart enough to distinguish between new and updated. Once an article / tip has been updated the status changes to updated. Then the newsletter goes to look at the status and sees "updated" and proceeds accordingly.
I see problem, though. It will be something we'll consider looking at.
Thanks,
Sean Ewington
CodeProject
|
|
|
|
|
Great, thanks 
But as said this is a minor detail and probably most of the users survive without the fix
|
|
|
|
|
With last few articles/tips I've noticed that a Visual Studio version tag has been automatically added to the article.
For example Writing into a file from database[^], I never selected VS2013 tag and besides it's not the version used for creating the project. So my question is, why is the tag automatically added?
|
|
|
|
|
With pending articles and tips there's the possibility to leave a message while the article is in queue, but with blog posts this is not possible. In the end of the post there's only the following text
Comments and Discussions
Comments are only available once an article is submitted for publishing.
However, many blog posts suffer from formatting problems etc so it would be very handy to be able to discuss about the problems.
|
|
|
|
|
Hello Code project,
Some times we can see a old post also reopenend. It's better to add two more "From date" & "To Date" datetime functions in near the "Filter box".
So , it will automatically filter all questions or answers based on date criteria also.
|
|
|
|
|
Possible, but I can't see the benefit.
cheers
Chris Maunder
|
|
|
|
|
As we all have noticed (With we, I'm referring to those that's frequenting the spam and abuse forum as well as the moderation queue) the russian spambot is back.
And something needs to be done to get the work load and the response time down.
I don't have very much to say about the moderation queue, it works really well. It catches almost everything with very few false positives and is easy enough to work on.
If I should complain about anything, it's a bit slow loading, so if you could tune the priority a teensy bit I'd be happy.
Anyhow, hats off to Dennis and the rest of the crew for a good job.
So what's the problem then?
Well, the moderation queue can actually be handled fairly easy as far as I'm concerned
The bottleneck is what happens afterwards. Cleaning up the offending accounts.
The procedure goes basically like this:
First check if they have been reported before or not.
If not, post about them in the spam forum.
Check posts from other members if other spammer accounts need to be removed.
Double check if it's a probable spammer or not. If there is no obvious reason for why not (as the proof is already gone), trust the poster.
Report.
If it's the tenth report, add a note to the OP that it's been removed so that other member knows they don't need to check this post.
I know that all this work was put into order to minimize mistakes, and I'm not simply suggesting a change in number of reports necessary as it doesn't really do anything about the underlying problem.
I believe we need a different approach to the problem.
This is how I see it: Someone is a spammer if they post spam. So the check on whether someone is a spammer or not, should be done when a message is reported or rejected from the moderation queue.
This should be automatic, we should not need to report the user as a spammer.
But there obviously needs to be some safety catches in the system. And actually, with the current system we simply trust the person that cleaned up the moderation queue, so that safety catch isn't there.
Anyway,
First we need some kind of throttling in the system. A lot of it is already in place, but bear with me.
- I don't like captchas and similar and I'm having some doubts on how efficient it would be, but your account is something you register only once if you're a normal user, and then it has to be considered OK.
- A user should be blocked from posting whenever they have more than a certain number of messages in the moderation queue.
Whenever the messages have been approved the account is unblocked.
However, any user that gets a message rejected should automatically get their account disabled.
There's an obvious drawback with this approach, if I click the wrong button, the user would get blocked and I wouldn't even know I did something wrong.
So we need at least two accepts or rejects on a message. This is twice as much work in the moderation queue, but it is already safer than the system we have now, and it almost completely removes the messy disorganized work in the spam forum.
Note that this suggestion refers to spam in the moderation queue, spam that gets through to the forums is a whole different problem. If regular Joe realizes they can kill an account with two spam reports it will get heavily misused.
Discuss.
|
|
|
|
|
I have made a change. Let's see how this initial stage 1 affects the amount.
I have 2 more changes to make after this.
With regards to auto-kill, we did that and it was a disaster. Just one or two false positives slipping through caused high-rep members to have their accounts nuked. We need to err on the side of caution.
cheers
Chris Maunder
|
|
|
|
|
It might be so that I'm alone with this opinion, but it's not the spam that is causing the problem at the moment, it's the spammers. The handling of them is unorganised at best.
Auto-kill was a disaster because it didn't have a safety catch, and honestly, what's there at the moment doesn't either, unless you're high-rep that is.
There is only one person that's checking the spam in the queue, and the others simply trusts that person. How is two or three people saying it's spam worse than one?
Anyway, make it more than two people checking the spam, make it necessary to have several spam messages to trigger an auto-kill, it's the principal I find important here, not the trigger levels.
It's the message that defines the spammer, not a post in a forum.
|
|
|
|
|
Jörgen Andersson wrote: one person that's checking the spam in the queue, and the others simply trusts that person
Jörgen Andersson wrote: make it more than two people checking the spam, make it necessary to have several spam messages to trigger an auto-kill
Doesn't statement 1 render statement 2 ineffective? I get the gist of what you're saying: "get a second opinion", but if people truly are following a single person then this is nullified.
You also wrote: A user should be blocked from posting whenever they have more than a certain number of messages in the moderation queue.
That's the idea, exactly. That's already on the list.
cheers
Chris Maunder
|
|
|
|
|
Well, statement 1 is the current state, and statement 2 is a suggestion for how to change it. I don't see how statement 1 affects statement 2.
Anyway,
My original thought was that the owner accounts for all the messages that gets rejected in the moderation queue, should get moved to a purgatory list.
Accessible by for example protectors.
They should get marked with spammer probability weighed by activity. If they have more spam than proper messages (give or take) they get marked for deletion and will be purged after a week or so if no one marks them as OK.
And obviously the other way around for accounts having more proper messages than spam, they would need to be reported as spammer by a certain number of people.
The advantage of this type of system is that it more or less just automatises how it works today.
And the drawback, well I believe it would be quite a much bigger investment in time for you guys, that's my main reason for not suggesting it to start with.
|
|
|
|
|
Jörgen Andersson wrote: They should get marked with spammer probability weighed by activity
Can you give me an example? My feeling is that a message is either spam or not (give or take the rare instances where someone posts spam but doesn't realise they are being spammy - eg link to their own project or product that's posted in-context). So for me it's not about whether they have "more spam than proper messages". A single spam message means they are gone.
I guess I'm missing a nuance of your suggestion (sorry - been a busy and tiring week...)
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: A single spam message means they are gone.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
