The on-going debate of pros and cons of issue/post/patch voting or subscription is largely hypothetical: neither camp has strong proofs they are right. (It is further clouded by the other part of the patch delay problem, which is lack of superbly experienced Drupal coders who actually are able to understand and intelligently review the more complicated patches.)<div>
<br></div><div>But remember the other reason to install at least <span class="Apple-style-span" style="font-style: italic;">subscription</span> to <span class="Apple-style-span" style="font-style: italic;">individual issues</span>: we would get rid of all the &quot;+1&quot; and &quot;subscribing&quot; little posts that plague many threads and make them hardly readable.</div>
<div>If then we had a way of selecting posts with patches sorted by number of subscribers, we&#39;d be able to see what patches are most sorely needed to be reviewed and committed. Linking that to the d.o. menu would help a lot, too.</div>
<div><br></div><div>In 6 months we can evaluate whether or not such issue subscription sorting helped the whole patch stalling situation. I believe it will, but even if it won&#39;t, it will be extremely useful.<br></div>
<div><br><br>
<br><br><div class="gmail_quote">On Sat, Nov 1, 2008 at 10:28 AM, Vivek Puri <span dir="ltr">&lt;<a href="mailto:crystalcube@yahoo.com">crystalcube@yahoo.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
voting will not solve the problem , popularity factor is already one of causes of problem. The problem stems from lack of fair way of defining how critical a given issue is. Right now everything to do with D7 currently gets most attention, leaving the bugs in production releases with lack of attention from the community.<br>

<br>
There should be a queue based on a factor which defines fairness something like this ,<br>
&nbsp;Secuity &gt; known bug/patch &gt; issue<br>
&nbsp;core &gt; module<br>
&nbsp;Current Stable version ( 6) &gt; last stable version (5) &gt; development version (7)<br>
<br>
Of course there is also a need for some kind of accountability as why a patch for a bug in production version has not been committed for x.y.z time period. But we can ignore that ...being an open source project ;) . Currently new release is favored over resolving bugs in current release.<br>

<br></blockquote></div><br></div>