On Feb 18, 2011, at 7:07 AM, Vinzent Steinberg wrote:
> 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.
I recently had some interaction with the git project. I was surprised to find
out that they do not have an issue tracker. They rely solely on their single
mailing list. If someone sends a patch to that list, and no one reviews it,
then it is lost. To quote Junio Hamano, the git project leader:
What we do is to take advantage of the fact that issues people do care
about are important ones, and others that nobody cares about are not worth
pursuing.
In a sense, "people forgetting" is a lot more important than "people
remembering" to filter unimportant issues (issues that are so unimportant
that even the original complainer does not bother to come back and
re-raise it).
Now in my opinion this isn't a very good system, though it's perhaps better
suited to a larger project like git. In our system, once someone opens an
issue or a pull request, even if no one looks at it for a month, it is still
siting there, and someone might some day notice that it needs review and do
something about it.
The thing is, people review the patches they are most interested in. If
someone creates a patch concerning a piece of code that I have written (like
the ODE module), or some code that I am working on (like integration), I am
much more likely to review the patch. On the other hand, I specifically don't
review patches to things that I do not understand mathematically, like the
quantum stuff, because that wouldn't be fair to anyone involved (all I could do
is see if the code looks alright and if the tests pass).
>
> It may be possible to make deals like "I review your patch, and you
> review mine".
Yes, I did this a few times last month when I had all the important pull
requests open. It's a good system that benefits everyone. If two people are
sitting around wanting someone to review their code, the least they can do is
review someone else's code. If this is organized between the two people so
that this actually causes both codes to be reviewed, then it will work out well.
>
> Please note that pull request are already much nicer than patches to
> the mailinglist, because they won't be forgotten.
Yes, basically what I was saying above.
>
> 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
Aaron Meurer
--
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.
