On 18 Feb., 10:49, smichr <[email protected]> wrote: > I can't find the message where you discussed a 24 hour wait, VInzent, > but I think we could generate some other principles that would help > development: > > 1) Like Robert's Rules of Order, before beginning to make a solution > for an issue, seek a "second" for your motion. That affirmation would > indicate that someone thinks your proposal for a solution is worth > pursuing.
This is a general rule, it correlates with "release early, release often". If you want to avoid "wasting time" (if you want to call it like this) it makes sense to speak about your plans with the community. "Getting your code in" is relatively easy in SymPy, compared to projects like Linux though. > 2) Ideally, besides a second there should maybe be "thirds": one or > more persons that would be willing to review the work. > > 3) Make a pull request when the work is finished. > > 4) After 24 hours, or when that pull request comes next in the queue, > or when it is agreed that the pull should move forward...respond in a > timely manner to keep the pull active. > > As to the processing of pull requests: if we processed pull requests > in the order received or have some mechanism -- push credit based on > lines reviewed? -- to decide when one might jump ahead, this would > encourage review of existing requests. A pull request mightbe skipped > over if the pull doesn't receive response to feedback within a day or > some reasonable time frame. In my opinion, this is a general resource problem of Open Source projects. Ideally a pull request would be reviewed immediately. But this is not possible due to limited resources. You need to find someone to review your work, or it won't get in. Even larger projects like Python or Linux suffer from this problem. We could introduce a more systematic approach, but in the end everyone works in his free time on SymPy. When and which patch is reviewed depends on occasion and interest of the reviewer. This is not optimal, but it is like it should be in such a project. It may be possible to make deals like "I review your patch, and you review mine". Please note that pull request are already much nicer than patches to the mailinglist, because they won't be forgotten. I agree that it makes sense to create a wiki page on "how to get your code into SymPy", which would be essentially your 4 points. Vinzent -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
