www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Managing the review queue

reply dsimcha <dsimcha yahoo.com> writes:
 From observing the review processes for std.parallelism and 
std.net.isemail, I think our review process needs some tweaking.  There 
are two key issues:

1.  The pace of reviews is glacial unless there's a vote date near. 
Only 4 people have reviewed std.net.isemail, and that's counting any 
participation in the discussion as "review".  This module doesn't have a 
vote date yet.  IIRC only two people reviewed std.parallelism during its 
first two weeks of review.  Furthermore, it took some time after I 
requested review for the "official" review period to start.  As a 
solution all requests for review should come with a tentative vote date 
to prevent the module from being held in limbo indefinitely and move the 
review queue along.

2.  Reviews that prompt major changes right before the vote date are 
stressful.  A looming deadline is not conducive to careful discussion 
and consideration of suggestions, especially those that are non-trivial 
to understand and/or implement.

I propose that all review periods last one week for small modules or two 
weeks for large modules, subject to extension if the review process is 
still yielding good discussion near the vote date or "stashing" if the 
author needs time to discuss specific issues that were raised and/or 
design and implement changes.  When a module is stashed, it is no longer 
officially in review and the next item in the review queue, if any, can 
begin the process.  As soon as this item is done, review of the stashed 
item is resumed.  Right now, std.parallelism is stashed until 
std.net.isemail is finished.

To prevent the community from being overwhelmed, multiple reviews may 
not take place concurrently but a review may take place concurrently 
with a vote.  Contention for the review queue is an issue in theory, but 
that's a problem we'd like to have and can work out on an ad-hoc basis 
should it arise.

More specifically, the pace of reviews for std.net.isemail has been 
glacial.  If everyone who intends to review it has done so, we should 
move on to a vote.  If anyone intends to review this module but hasn't 
yet, please do so or at least state your intention to do so.
Mar 27 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-03-27 20:53, dsimcha wrote:
  From observing the review processes for std.parallelism and
 std.net.isemail, I think our review process needs some tweaking.  There
 are two key issues:
 
 1.  The pace of reviews is glacial unless there's a vote date near.
 Only 4 people have reviewed std.net.isemail, and that's counting any
 participation in the discussion as "review".  This module doesn't have a
 vote date yet.  IIRC only two people reviewed std.parallelism during its
 first two weeks of review.  Furthermore, it took some time after I
 requested review for the "official" review period to start.  As a
 solution all requests for review should come with a tentative vote date
 to prevent the module from being held in limbo indefinitely and move the
 review queue along.
 
 2.  Reviews that prompt major changes right before the vote date are
 stressful.  A looming deadline is not conducive to careful discussion
 and consideration of suggestions, especially those that are non-trivial
 to understand and/or implement.
 
 I propose that all review periods last one week for small modules or two
 weeks for large modules, subject to extension if the review process is
 still yielding good discussion near the vote date or "stashing" if the
 author needs time to discuss specific issues that were raised and/or
 design and implement changes.  When a module is stashed, it is no longer
 officially in review and the next item in the review queue, if any, can
 begin the process.  As soon as this item is done, review of the stashed
 item is resumed.  Right now, std.parallelism is stashed until
 std.net.isemail is finished.
 
 To prevent the community from being overwhelmed, multiple reviews may
 not take place concurrently but a review may take place concurrently
 with a vote.  Contention for the review queue is an issue in theory, but
 that's a problem we'd like to have and can work out on an ad-hoc basis
 should it arise.
 
 More specifically, the pace of reviews for std.net.isemail has been
 glacial.  If everyone who intends to review it has done so, we should
 move on to a vote.  If anyone intends to review this module but hasn't
 yet, please do so or at least state your intention to do so.
Overall, your suggestions are good. Personally, my problem with reviews is that I have enough going on and they take enough time and concentration to do that I end up setting them aside to do later and then have trouble getting around to them. I've been intending to look at both std.parallelism and std.net.isemail (Am I the only one who thinks Ishmael when I see that? LOL), but I've been busy. Shorter review periods are both good and bad, because they force you to take the time to review them rather than putting it off, thereby actually encouraging reviews, but if they're too short, some folks will miss them entirely or not have the time to come up with solid feedback. Overall, I think that what you're suggesting is solid. - Jonathan M Davis
Mar 27 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2011 8:53 PM, dsimcha wrote:
  From observing the review processes for std.parallelism and std.net.isemail, I
 think our review process needs some tweaking. There are two key issues:

 1. The pace of reviews is glacial unless there's a vote date near. Only 4
people
 have reviewed std.net.isemail, and that's counting any participation in the
 discussion as "review". This module doesn't have a vote date yet. IIRC only two
 people reviewed std.parallelism during its first two weeks of review.
 Furthermore, it took some time after I requested review for the "official"
 review period to start. As a solution all requests for review should come with
a
 tentative vote date to prevent the module from being held in limbo indefinitely
 and move the review queue along.
I know that reviews can be frustratingly slow. It's mainly because we have a smallish community.
 2. Reviews that prompt major changes right before the vote date are stressful.
A
 looming deadline is not conducive to careful discussion and consideration of
 suggestions, especially those that are non-trivial to understand and/or
implement.

 I propose that all review periods last one week for small modules or two weeks
 for large modules, subject to extension if the review process is still yielding
 good discussion near the vote date or "stashing" if the author needs time to
 discuss specific issues that were raised and/or design and implement changes.
 When a module is stashed, it is no longer officially in review and the next
item
 in the review queue, if any, can begin the process. As soon as this item is
 done, review of the stashed item is resumed. Right now, std.parallelism is
 stashed until std.net.isemail is finished.

 To prevent the community from being overwhelmed, multiple reviews may not take
 place concurrently but a review may take place concurrently with a vote.
 Contention for the review queue is an issue in theory, but that's a problem
we'd
 like to have and can work out on an ad-hoc basis should it arise.

 More specifically, the pace of reviews for std.net.isemail has been glacial. If
 everyone who intends to review it has done so, we should move on to a vote. If
 anyone intends to review this module but hasn't yet, please do so or at least
 state your intention to do so.
Different people have interests in different things. I don't think a person interested in std.parallelism would necessarily have any interest in std.net.isemail, and vice versa, so those can be done in parallel (!). A further issue with the review process is that the bulk of people won't look at something until it is actually released. I think the only way to deal with this is to be willing to correct deficiencies found after release.
Mar 28 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 A further issue with the review process is that the bulk of people won't look
at
 something until it is actually released. I think the only way to deal with this
 is to be willing to correct deficiencies found after release.
Please clarify "release". If you mean making the code and documentation public and conveniently accessible, that's the point of the review process. If you mean actually including it with the DMD distribution, then maybe we need an "incubator" package as others have suggested. Things would get in incubator after abbreviated review. While in incubator we'd make no guarantees about their stability or even their continued inclusion. The "real" review would take place over a release cycle or two, while the module was in incubator. After each release cycle, we'd make a three-way decision. A module can: 1. Be declared stable and promoted to std. 2. Be declared not worthwhile and removed. 3. Kept in incubator pending further review and improvements.
Mar 28 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2011 12:18 PM, dsimcha wrote:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 A further issue with the review process is that the bulk of people won't look
at
 something until it is actually released. I think the only way to deal with this
 is to be willing to correct deficiencies found after release.
Please clarify "release". If you mean making the code and documentation public and conveniently accessible, that's the point of the review process. If you mean actually including it with the DMD distribution, then maybe we need an "incubator" package as others have suggested. Things would get in incubator after abbreviated review. While in incubator we'd make no guarantees about their stability or even their continued inclusion. The "real" review would take place over a release cycle or two, while the module was in incubator. After each release cycle, we'd make a three-way decision. A module can: 1. Be declared stable and promoted to std. 2. Be declared not worthwhile and removed. 3. Kept in incubator pending further review and improvements.
I have thought in the past about putting such modules into another package, call it "foo" for lack of a better name, and put it in the dmd distribution. If the package pans out in real life, then move it to std. So, yes, I think your idea is a good one.
Mar 28 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 I have thought in the past about putting such modules into another package,
call 
 it "foo" for lack of a better name, and put it in the dmd distribution. If the 
 package pans out in real life, then move it to std. So, yes, I think your idea 
 is a good one.
It's a nice idea. Possible names: "std.experimental", "std.unstable" or "std.minefield" :-) In Python there is kind of built-in namespace named "future" that you import as module, it contains even new basic language features in testing (like integer division!). I'd like the same in D2 too, for experimental features. Bye, bearophile
Mar 28 2011
next sibling parent reply Graham Fawcett <fawcett uwindsor.ca> writes:
On Mon, 28 Mar 2011 15:32:44 -0400, bearophile wrote:

 Walter:
 
 I have thought in the past about putting such modules into another
 package, call it "foo" for lack of a better name, and put it in the dmd
 distribution. If the package pans out in real life, then move it to
 std. So, yes, I think your idea is a good one.
It's a nice idea. Possible names: "std.experimental", "std.unstable" or "std.minefield" :-)
Personally I like the experimental/incubator idea (though it had better not get a 'std' prefix!). I'm not sure the D community is large enough to support a more formal review process (yet).
 In Python there is kind of built-in namespace named "future" that you
 import as module, it contains even new basic language features in
 testing (like integer division!). I'd like the same in D2 too, for
 experimental features.
I don't see the connection. '__future__' in Python isn't for experimental features, nor is it for introducing stdlib changes. It's a way to 'import' language features which become standard in later releases. For example, as you know, the 'print' statement becomes a function in Python 3.0, but you can disable the print statement in Python 2.6+ via 'from __future__ import print_function'. Graham
Mar 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Graham Fawcett:

 I don't see the connection. '__future__' in Python isn't for experimental 
 features, nor is it for introducing stdlib changes. It's a way to 'import' 
 language features which become standard in later releases.
But the end result is the same: if they find troubles in a feature present just in __future__, then I am sure they fix them before the feature becomes standard. Bye, bearophile
Mar 28 2011
parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 29, 11 04:04, bearophile wrote:
 Graham Fawcett:

 I don't see the connection. '__future__' in Python isn't for experimental
 features, nor is it for introducing stdlib changes. It's a way to 'import'
 language features which become standard in later releases.
But the end result is the same: if they find troubles in a feature present just in __future__, then I am sure they fix them before the feature becomes standard. Bye, bearophile
I disagree. Python's future statement provides features that will certainly be enabled. It's a feature to provide smoother code compatibility with earlier versions. Every decision is pretty much settled when it is available in __future__, and the only step left is to enable it by default. This is not the case for incubator/foo/experimental. There is no guarantee that the module must be voted in, nor the interface will be the same when transitioning to std.
Mar 28 2011
parent bearophile <bearophileHUGS lycos.com> writes:
KennyTM~:

 Python's future statement provides features that will certainly be 
 enabled. It's a feature to provide smoother code compatibility with 
 earlier versions. Every decision is pretty much settled when it is 
 available in __future__, and the only step left is to enable it by default.
 
 This is not the case for incubator/foo/experimental. There is no 
 guarantee that the module must be voted in, nor the interface will be 
 the same when transitioning to std.
You are right, there are important differences. Beside a Phobos module like std.experimental, I'd like a way to activate experimental features in D too. There is a similar feature in Haskell too, and it's used a lot. Bye, bearophile
Mar 28 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/28/2011 09:32 PM, bearophile wrote:
 Walter:

 I have thought in the past about putting such modules into another package,
call
 it "foo" for lack of a better name, and put it in the dmd distribution. If the
 package pans out in real life, then move it to std. So, yes, I think your idea
 is a good one.
It's a nice idea. Possible names: "std.experimental", "std.unstable" or "std.minefield" :-)
std.experimental is better than std.foo, because 'foo' is far too useful as variable name ;-) Denis -- _________________ vita es estrany spir.wikidot.com
Mar 28 2011
prev sibling next sibling parent reply Jonas Drewsen <jdrewsen nospam.com> writes:
On 28/03/11 21.19, Walter Bright wrote:
 On 3/28/2011 12:18 PM, dsimcha wrote:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 A further issue with the review process is that the bulk of people
 won't look at
 something until it is actually released. I think the only way to deal
 with this
 is to be willing to correct deficiencies found after release.
Please clarify "release". If you mean making the code and documentation public and conveniently accessible, that's the point of the review process. If you mean actually including it with the DMD distribution, then maybe we need an "incubator" package as others have suggested. Things would get in incubator after abbreviated review. While in incubator we'd make no guarantees about their stability or even their continued inclusion. The "real" review would take place over a release cycle or two, while the module was in incubator. After each release cycle, we'd make a three-way decision. A module can: 1. Be declared stable and promoted to std. 2. Be declared not worthwhile and removed. 3. Kept in incubator pending further review and improvements.
I have thought in the past about putting such modules into another package, call it "foo" for lack of a better name, and put it in the dmd distribution. If the package pans out in real life, then move it to std. So, yes, I think your idea is a good one.
Please do! I would love to put in the libcurl wrapper in for early feedback. Libcurl supports many other protocols that just HTTP, and it would be very nice to try out the wrapper design initially by implementing HTTP only support. Based on the feedback of that the rest of the protocols could be implemented. /Jonas
Mar 28 2011
parent spir <denis.spir gmail.com> writes:
On 03/28/2011 10:32 PM, Jonas Drewsen wrote:
 On 28/03/11 21.19, Walter Bright wrote:
 On 3/28/2011 12:18 PM, dsimcha wrote:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 A further issue with the review process is that the bulk of people
 won't look at
 something until it is actually released. I think the only way to deal
 with this
 is to be willing to correct deficiencies found after release.
Please clarify "release". If you mean making the code and documentation public and conveniently accessible, that's the point of the review process. If you mean actually including it with the DMD distribution, then maybe we need an "incubator" package as others have suggested. Things would get in incubator after abbreviated review. While in incubator we'd make no guarantees about their stability or even their continued inclusion. The "real" review would take place over a release cycle or two, while the module was in incubator. After each release cycle, we'd make a three-way decision. A module can: 1. Be declared stable and promoted to std. 2. Be declared not worthwhile and removed. 3. Kept in incubator pending further review and improvements.
I have thought in the past about putting such modules into another package, call it "foo" for lack of a better name, and put it in the dmd distribution. If the package pans out in real life, then move it to std. So, yes, I think your idea is a good one.
Please do! I would love to put in the libcurl wrapper in for early feedback. Libcurl supports many other protocols that just HTTP, and it would be very nice to try out the wrapper design initially by implementing HTTP only support. Based on the feedback of that the rest of the protocols could be implemented.
This idea seems to find large support very fast... Denis -- _________________ vita es estrany spir.wikidot.com
Mar 28 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 28/03/2011 20:19, Walter Bright wrote:
 On 3/28/2011 12:18 PM, dsimcha wrote:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 A further issue with the review process is that the bulk of people
 won't look at
 something until it is actually released. I think the only way to deal
 with this
 is to be willing to correct deficiencies found after release.
Please clarify "release". If you mean making the code and documentation public and conveniently accessible, that's the point of the review process. If you mean actually including it with the DMD distribution, then maybe we need an "incubator" package as others have suggested. Things would get in incubator after abbreviated review. While in incubator we'd make no guarantees about their stability or even their continued inclusion. The "real" review would take place over a release cycle or two, while the module was in incubator. After each release cycle, we'd make a three-way decision. A module can: 1. Be declared stable and promoted to std. 2. Be declared not worthwhile and removed. 3. Kept in incubator pending further review and improvements.
I have thought in the past about putting such modules into another package, call it "foo" for lack of a better name, and put it in the dmd distribution. If the package pans out in real life, then move it to std. So, yes, I think your idea is a good one.
Hum, this seems like an very interesting idea, it should definitely be considered (perhaps, especially so if the number of people participating in the review process remains low?). So, a kind of incubator/experimental package. The modules here should be fairly stable (in terms of bugs), but the API would not be stable, it would change as people used the lib, feedback was received, changes were made, etc. -- Bruno Medeiros - Software Engineer
Apr 01 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/28/2011 09:18 PM, dsimcha wrote:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 A further issue with the review process is that the bulk of people won't look
at
 something until it is actually released. I think the only way to deal with this
 is to be willing to correct deficiencies found after release.
Please clarify "release". If you mean making the code and documentation public and conveniently accessible, that's the point of the review process. If you mean actually including it with the DMD distribution, then maybe we need an "incubator" package as others have suggested. Things would get in incubator after abbreviated review. While in incubator we'd make no guarantees about their stability or even their continued inclusion. The "real" review would take place over a release cycle or two, while the module was in incubator. After each release cycle, we'd make a three-way decision. A module can: 1. Be declared stable and promoted to std. 2. Be declared not worthwhile and removed. 3. Kept in incubator pending further review and improvements.
Anyway,n this is far better than premature adoption (mainly because later found issues often reveal design bugs that require major modification). Denis -- _________________ vita es estrany spir.wikidot.com
Mar 28 2011