<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"
	>
<channel>
	<title>Comments on: An economic solution to reviewing load</title>
	<atom:link href="http://blogs.law.harvard.edu/pamphlet/2009/06/15/an-economic-solution-to-reviewing-load/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.law.harvard.edu/pamphlet/2009/06/15/an-economic-solution-to-reviewing-load/</link>
	<description>on scholarly communication</description>
	<lastBuildDate>Wed, 02 Dec 2009 21:25:13 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Fernando Pereira</title>
		<link>http://blogs.law.harvard.edu/pamphlet/2009/06/15/an-economic-solution-to-reviewing-load/comment-page-1/#comment-23</link>
		<dc:creator>Fernando Pereira</dc:creator>
		<pubDate>Thu, 18 Jun 2009 15:47:45 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.law.harvard.edu/pamphlet/?p=124#comment-23</guid>
		<description>@Thomas Schiex: Variants of your idea have been floating around the computer science community for decades; the most common variant has authors earn points by reviewing, rather than than having their accounts topped up yearly. However, in my opinion the main problems in computer science are (1) peak reviewing load caused by conference deadlines, and (2) lack of reviewing history for submission across different conferences and years of the same conference, leading to much redundant reviewing.  Stuart&#039;s and your proposal try to manage total load, which in my view is much less of an issue. Indeed, a major CS conference, VLDB, is in the process of switching to a year-round, fast-publishing electronic journal submission format, with the annual conference being just the aggregation of papers accepted the previous year, in an effort to correct the problems I mentioned.</description>
		<content:encoded><![CDATA[<p>@Thomas Schiex: Variants of your idea have been floating around the computer science community for decades; the most common variant has authors earn points by reviewing, rather than than having their accounts topped up yearly. However, in my opinion the main problems in computer science are (1) peak reviewing load caused by conference deadlines, and (2) lack of reviewing history for submission across different conferences and years of the same conference, leading to much redundant reviewing.  Stuart&#8217;s and your proposal try to manage total load, which in my view is much less of an issue. Indeed, a major CS conference, VLDB, is in the process of switching to a year-round, fast-publishing electronic journal submission format, with the annual conference being just the aggregation of papers accepted the previous year, in an effort to correct the problems I mentioned.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thomas Schiex</title>
		<link>http://blogs.law.harvard.edu/pamphlet/2009/06/15/an-economic-solution-to-reviewing-load/comment-page-1/#comment-20</link>
		<dc:creator>Thomas Schiex</dc:creator>
		<pubDate>Thu, 18 Jun 2009 08:40:19 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.law.harvard.edu/pamphlet/?p=124#comment-20</guid>
		<description>Yes, I do think we need to introduce some viscosity in submission as the energy required for reviewing is such that it hampers reviewing quality and lowers publication quality. It also takes too much time from reviewers.

I must say that I don&#039;t like &quot;cash-based&quot; restriction mechanisms. Even if special waivers are enforced, there are side-effects (threshold effects, imperfect waiving design...) that may prevent somebody from publishing for financial reasons although the work is good.

One approach to this problem would be to create a virtual money (easy to manage thanks to IT and the web). Each scientist that wants to publish should subscribe to a central worlwide website. He will get an initial fund of (let say) 30 points. Each submission costs 6 points. If the paper is accepted, you get 3 points back. If it is rejected you get nothing. If you don&#039;t like these numbers for some reason, they can be changed.

Every year, you may get a donation that brings your account to 12 points (if lower) from the web site. A paper with multiple authors requires payment by all authors, with a (possibly non linear) discount based on the # of authors.

The number one difficulty is to make this &quot;virtual money&quot; acceptable by major journals and conferences. But the scheme is otherwise simple to implement in terms of required IT. The name/affiliation appearing on the paper published would be directly taken form the central website, preventing &quot;fake accounts&quot;.

There is also no way in the scheme presented to make this virtual money &quot;real&quot; (contrarily to second life money).</description>
		<content:encoded><![CDATA[<p>Yes, I do think we need to introduce some viscosity in submission as the energy required for reviewing is such that it hampers reviewing quality and lowers publication quality. It also takes too much time from reviewers.</p>
<p>I must say that I don&#8217;t like &#8220;cash-based&#8221; restriction mechanisms. Even if special waivers are enforced, there are side-effects (threshold effects, imperfect waiving design&#8230;) that may prevent somebody from publishing for financial reasons although the work is good.</p>
<p>One approach to this problem would be to create a virtual money (easy to manage thanks to IT and the web). Each scientist that wants to publish should subscribe to a central worlwide website. He will get an initial fund of (let say) 30 points. Each submission costs 6 points. If the paper is accepted, you get 3 points back. If it is rejected you get nothing. If you don&#8217;t like these numbers for some reason, they can be changed.</p>
<p>Every year, you may get a donation that brings your account to 12 points (if lower) from the web site. A paper with multiple authors requires payment by all authors, with a (possibly non linear) discount based on the # of authors.</p>
<p>The number one difficulty is to make this &#8220;virtual money&#8221; acceptable by major journals and conferences. But the scheme is otherwise simple to implement in terms of required IT. The name/affiliation appearing on the paper published would be directly taken form the central website, preventing &#8220;fake accounts&#8221;.</p>
<p>There is also no way in the scheme presented to make this virtual money &#8220;real&#8221; (contrarily to second life money).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fernando Pereira</title>
		<link>http://blogs.law.harvard.edu/pamphlet/2009/06/15/an-economic-solution-to-reviewing-load/comment-page-1/#comment-16</link>
		<dc:creator>Fernando Pereira</dc:creator>
		<pubDate>Tue, 16 Jun 2009 04:30:39 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.law.harvard.edu/pamphlet/?p=124#comment-16</guid>
		<description>I don&#039;t think this adds up. Consider a typical academic CS research group with one professor and a few graduate students. As is typical, as a conference deadline approaches, they have several papers in the works, say four, in different states of completion; maybe one is in very good shape, two in fair shape, and the other in poor shape (these are again typical numbers in my experience). If just one paper is accepted, the professor and one student attend the conference, at a typical cost of $4000 for travel, accomodation, and conference registration. If three papers are accepted, maybe the professor and three students attend, at a total cost of $8000. Compared with those costs, the difference between $50 and $200 is utterly trivial; just a couple of slightly better meals, or a cab to the airport instead of the shuttle, would make the difference. The only way this could work would be to have submission charges that are significant relative to the other costs of paper creation and presentation. But if the charges were that high for a given venue, then 1) other venues would undercut it, and 2) rejections would lead to open warfare with authors claiming they were swindled of their fees by inappropriate rejections. The lack of incentive alignment between getting as much from submission fees as possible and doing as little in reviewing as possible would be very destructive of already fragile institutions.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t think this adds up. Consider a typical academic CS research group with one professor and a few graduate students. As is typical, as a conference deadline approaches, they have several papers in the works, say four, in different states of completion; maybe one is in very good shape, two in fair shape, and the other in poor shape (these are again typical numbers in my experience). If just one paper is accepted, the professor and one student attend the conference, at a typical cost of $4000 for travel, accomodation, and conference registration. If three papers are accepted, maybe the professor and three students attend, at a total cost of $8000. Compared with those costs, the difference between $50 and $200 is utterly trivial; just a couple of slightly better meals, or a cab to the airport instead of the shuttle, would make the difference. The only way this could work would be to have submission charges that are significant relative to the other costs of paper creation and presentation. But if the charges were that high for a given venue, then 1) other venues would undercut it, and 2) rejections would lead to open warfare with authors claiming they were swindled of their fees by inappropriate rejections. The lack of incentive alignment between getting as much from submission fees as possible and doing as little in reviewing as possible would be very destructive of already fragile institutions.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
