<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: New Feature Code-Named Rake</title>
	<link>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html</link>
	<description></description>
	<pubDate>Mon, 13 Oct 2008 02:19:07 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.2</generator>

	<item>
		<title>by: Rajkumar Kanagasingam</title>
		<link>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11673</link>
		<pubDate>Sat, 29 Sep 2007 14:28:22 +0000</pubDate>
		<guid>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11673</guid>
					<description>Hi Friends,

I had a e-mail inquiry about my previous post.

My articles appeared in the 

http://www.theelectroniceconomist.com/index.html

Thanks,

Rajkumar</description>
		<content:encoded><![CDATA[<p>Hi Friends,</p>
<p>I had a e-mail inquiry about my previous post.</p>
<p>My articles appeared in the </p>
<p><a href='http://www.theelectroniceconomist.com/index.html' rel='nofollow'>http://www.theelectroniceconomist.com/index.html</a></p>
<p>Thanks,</p>
<p>Rajkumar<br />
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Rajkumar Kanagasingam</title>
		<link>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11620</link>
		<pubDate>Tue, 25 Sep 2007 04:08:02 +0000</pubDate>
		<guid>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11620</guid>
					<description>Hi Cris,

You rightly said, &quot; ...Under 7-10 days should be the worst case scenerio...&quot;

Everytime I have submitted my articles, I was nervous what would happen to them. 

But your editorial team is very effective. Before I submit I check number issues. 

Once it is approved by Ezine, I am submitting a few others. A couple of months ago 15 (fifteen) of my articles appeared in the www.economist.com.

My thanks to Ezine for the tirless task of helping to spread quality information to the world. 

Rajkumar</description>
		<content:encoded><![CDATA[<p>Hi Cris,</p>
<p>You rightly said, &#8221; &#8230;Under 7-10 days should be the worst case scenerio&#8230;&#8221;</p>
<p>Everytime I have submitted my articles, I was nervous what would happen to them. </p>
<p>But your editorial team is very effective. Before I submit I check number issues. </p>
<p>Once it is approved by Ezine, I am submitting a few others. A couple of months ago 15 (fifteen) of my articles appeared in the <a href='http://www.economist.com.' rel='nofollow'>www.economist.com.</a></p>
<p>My thanks to Ezine for the tirless task of helping to spread quality information to the world. </p>
<p>Rajkumar<br />
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Christopher M. Knight</title>
		<link>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11617</link>
		<pubDate>Sat, 22 Sep 2007 20:16:12 +0000</pubDate>
		<guid>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11617</guid>
					<description>Catalin,

4 weeks is never acceptable ever to wait for an article approval/review... Under 7-10 days should be the worst case scenerio, depending on load.

Thanks for your offer to assist. Sorry, we only hire editors who work locally in our office.</description>
		<content:encoded><![CDATA[<p>Catalin,</p>
<p>4 weeks is never acceptable ever to wait for an article approval/review&#8230; Under 7-10 days should be the worst case scenerio, depending on load.</p>
<p>Thanks for your offer to assist. Sorry, we only hire editors who work locally in our office.<br />
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Christina Sponias</title>
		<link>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11615</link>
		<pubDate>Sat, 22 Sep 2007 13:27:18 +0000</pubDate>
		<guid>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11615</guid>
					<description>Hi Programmer 1!

I know that while working we face several problems that our theories cannot predict.

My idea was to have expert editors checking first of all each article. So, they have to start from the final approval. 
They will see that the article has spelling and grammar mistakes and is somehow confusing, but it can be improved. The content is good and there is a message. So they approve it and select their category if they don’t agree with the category the author chose. If they don’t know if an article will be good after the improvement, it shall go to the “I don’t know” file.

The articles go to other editors not so experienced for grammar, spelling and organization and as soon as these mistakes are corrected the articles are directly approved without going back to the final approval team.

The problematic articles go back to the expert editors that already read them and know which their mistakes were. 
They check them again after the corrections. If the articles are ok they are approved, if not they are rejected.

A new editor shall never be responsible for the article’s category, since he or she doesn’t know well all the categories. 

Anyhow, this is my opinion. 
You can save time and energy if the most important part of the verification is done from the beginning by expert editors and all the rest by new editors. 

Have a nice weekend!

Christina</description>
		<content:encoded><![CDATA[<p>Hi Programmer 1!</p>
<p>I know that while working we face several problems that our theories cannot predict.</p>
<p>My idea was to have expert editors checking first of all each article. So, they have to start from the final approval.<br />
They will see that the article has spelling and grammar mistakes and is somehow confusing, but it can be improved. The content is good and there is a message. So they approve it and select their category if they don’t agree with the category the author chose. If they don’t know if an article will be good after the improvement, it shall go to the “I don’t know” file.</p>
<p>The articles go to other editors not so experienced for grammar, spelling and organization and as soon as these mistakes are corrected the articles are directly approved without going back to the final approval team.</p>
<p>The problematic articles go back to the expert editors that already read them and know which their mistakes were.<br />
They check them again after the corrections. If the articles are ok they are approved, if not they are rejected.</p>
<p>A new editor shall never be responsible for the article’s category, since he or she doesn’t know well all the categories. </p>
<p>Anyhow, this is my opinion.<br />
You can save time and energy if the most important part of the verification is done from the beginning by expert editors and all the rest by new editors. </p>
<p>Have a nice weekend!</p>
<p>Christina<br />
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Catalin</title>
		<link>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11614</link>
		<pubDate>Sat, 22 Sep 2007 08:09:32 +0000</pubDate>
		<guid>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11614</guid>
					<description>Chris, the waiting period 4 weeks is resonable for approving an article. I know what does it require this job as currently working as an editor. I can do this job for you too.</description>
		<content:encoded><![CDATA[<p>Chris, the waiting period 4 weeks is resonable for approving an article. I know what does it require this job as currently working as an editor. I can do this job for you too.<br />
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Programmer #1</title>
		<link>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11612</link>
		<pubDate>Sat, 22 Sep 2007 02:06:54 +0000</pubDate>
		<guid>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11612</guid>
					<description>Christina Sponias, 

 Being I created much of the content management system, I feel I need to respond here...

The editors are already split into specific tasks broken down into chunks, based on experience.  But the basis of how they are spread around can be very complex, and is based on a system of logic that has proven to be effective and refined over time.

    From a technical aspect of things, to have people be doing things as specific as just checking category's, would be very difficult &amp;#38; inefficient to implement   It would result in adding an extra step making the articles take twice as long to be approved.  

Let me explain, 

   A quick peak behind the scenes..   I had to come up with a way for teams of editors to be able to approve thousands of articles per day and keep everything 'in sync'. You don't want two editors working on the same thing at the same time for example. 

   So it works on a batch queuing system.  An editor gets a 'batch' of articles at a time, reserved for them. The order of the articles they receive is different depending on the experience of the editor, and various priority's that can be set per individual person, depending on the state of the existing articles in the system. 

(remember you are dealing with thousands of submits per day that go to around a dozen or so editors.   And an article can be in a number of different status's, such as a new submit, or existing articles that where edited now waiting to be re approved, on top of being prioritized by member status, and age of the current articles sitting in the primary approval pool, ect, this is a very complex system to maintain!)

  New editors will generally start out only getting basics, while the experienced editors will get plats first, or might be assigned for things like re-approvals, etc, etc.   So you must envision, the articles as being in separate waiting pools at any given time.  A primary pool of articles waiting to be approved, or re-approved, and smaller pools assigned for each editor.

    To have articles go to first pools designated to grammar..  then back into the main pool again, now waiting to go to designated category people, the article has now hopped from 

main pool-&amp;#62; grammar editor etc -&amp;#62; main pool -&amp;#62; category select people -&amp;#62; finally approved

  ..   which means it would often take perhaps twice as long for the article to reach a final approval.</description>
		<content:encoded><![CDATA[<p>Christina Sponias, </p>
<p> Being I created much of the content management system, I feel I need to respond here&#8230;</p>
<p>The editors are already split into specific tasks broken down into chunks, based on experience.  But the basis of how they are spread around can be very complex, and is based on a system of logic that has proven to be effective and refined over time.</p>
<p>    From a technical aspect of things, to have people be doing things as specific as just checking category&#8217;s, would be very difficult &amp; inefficient to implement   It would result in adding an extra step making the articles take twice as long to be approved.  </p>
<p>Let me explain, </p>
<p>   A quick peak behind the scenes..   I had to come up with a way for teams of editors to be able to approve thousands of articles per day and keep everything &#8216;in sync&#8217;. You don&#8217;t want two editors working on the same thing at the same time for example. </p>
<p>   So it works on a batch queuing system.  An editor gets a &#8216;batch&#8217; of articles at a time, reserved for them. The order of the articles they receive is different depending on the experience of the editor, and various priority&#8217;s that can be set per individual person, depending on the state of the existing articles in the system. </p>
<p>(remember you are dealing with thousands of submits per day that go to around a dozen or so editors.   And an article can be in a number of different status&#8217;s, such as a new submit, or existing articles that where edited now waiting to be re approved, on top of being prioritized by member status, and age of the current articles sitting in the primary approval pool, ect, this is a very complex system to maintain!)</p>
<p>  New editors will generally start out only getting basics, while the experienced editors will get plats first, or might be assigned for things like re-approvals, etc, etc.   So you must envision, the articles as being in separate waiting pools at any given time.  A primary pool of articles waiting to be approved, or re-approved, and smaller pools assigned for each editor.</p>
<p>    To have articles go to first pools designated to grammar..  then back into the main pool again, now waiting to go to designated category people, the article has now hopped from </p>
<p>main pool-&gt; grammar editor etc -&gt; main pool -&gt; category select people -&gt; finally approved</p>
<p>  ..   which means it would often take perhaps twice as long for the article to reach a final approval.<br />
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Christina Sponias</title>
		<link>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11607</link>
		<pubDate>Fri, 21 Sep 2007 21:35:24 +0000</pubDate>
		<guid>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11607</guid>
					<description>I had to do 1000 things after arriving home, so I couldn't really think about your problem before. I just wanted to send you an answer without delay because you answered my question.

Now I’m thinking…

Are you serious? Do you teach each editor Everything?? 
This is a waste of time and energy. You have to work as if the Ezine was a factory. 
Each editor has to do only one part of the work. People work faster and better doing only one thing.

So, you shall have a group of editors A, formed with the old editors that know very well the Ezine’s categories and which articles are decent for the Ezine, etc. that will be responsible for the main verification. 

They will be the first ones to read the article and see if it is ok, if it has meaning and if the author chose the correct category. If an article won’t pass from verification 1 there is no meaning on checking for grammar, spelling, etc. 
It is rejected from the beginning by the experts. 

Then you shall have a group of editors that will check the rest: spelling, grammar and synthesis while each article will be already approved by the experienced editors and in the right category.

This way you only have to prepare new editors for the group B. 
Editors on group B shall start learning all the categories while they are looking for writing mistakes but they are not responsible for anything.
They are the future editors A.</description>
		<content:encoded><![CDATA[<p>I had to do 1000 things after arriving home, so I couldn&#8217;t really think about your problem before. I just wanted to send you an answer without delay because you answered my question.</p>
<p>Now I’m thinking…</p>
<p>Are you serious? Do you teach each editor Everything??<br />
This is a waste of time and energy. You have to work as if the Ezine was a factory.<br />
Each editor has to do only one part of the work. People work faster and better doing only one thing.</p>
<p>So, you shall have a group of editors A, formed with the old editors that know very well the Ezine’s categories and which articles are decent for the Ezine, etc. that will be responsible for the main verification. </p>
<p>They will be the first ones to read the article and see if it is ok, if it has meaning and if the author chose the correct category. If an article won’t pass from verification 1 there is no meaning on checking for grammar, spelling, etc.<br />
It is rejected from the beginning by the experts. </p>
<p>Then you shall have a group of editors that will check the rest: spelling, grammar and synthesis while each article will be already approved by the experienced editors and in the right category.</p>
<p>This way you only have to prepare new editors for the group B.<br />
Editors on group B shall start learning all the categories while they are looking for writing mistakes but they are not responsible for anything.<br />
They are the future editors A.<br />
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Connie Ragen Green</title>
		<link>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11606</link>
		<pubDate>Fri, 21 Sep 2007 20:53:08 +0000</pubDate>
		<guid>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11606</guid>
					<description>Chris,
This is a great new feature that will again set you apart from others. Giving new life to seasoned articles is good for everyone.</description>
		<content:encoded><![CDATA[<p>Chris,<br />
This is a great new feature that will again set you apart from others. Giving new life to seasoned articles is good for everyone.<br />
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Christina Sponias</title>
		<link>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11605</link>
		<pubDate>Fri, 21 Sep 2007 19:44:57 +0000</pubDate>
		<guid>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11605</guid>
					<description>We have to do something about that…

Why don’t you have only old editors checking for the article’s meaning and choosing the correct category?
New editors would check only spelling, grammar and synthesis.</description>
		<content:encoded><![CDATA[<p>We have to do something about that…</p>
<p>Why don’t you have only old editors checking for the article’s meaning and choosing the correct category?<br />
New editors would check only spelling, grammar and synthesis.<br />
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Christopher M. Knight</title>
		<link>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11604</link>
		<pubDate>Fri, 21 Sep 2007 17:47:21 +0000</pubDate>
		<guid>http://blog.ezinearticles.com/2007/09/new-feature-code-named-rake.html#comment-11604</guid>
					<description>Editor inexperience is the cause.

They are required to know all 435 categories along with what should and shouldn't be accepted in each. It takes them 6+ weeks to begin to get it right.</description>
		<content:encoded><![CDATA[<p>Editor inexperience is the cause.</p>
<p>They are required to know all 435 categories along with what should and shouldn&#8217;t be accepted in each. It takes them 6+ weeks to begin to get it right.<br />
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
