Re: [PEPr] Call for votes on Math::Math_Polynomial

Keith Palmer Jr. wrote:

Re: [Maybe the proposals lack visibility. Do you have ideas on how we can improve the situation ?] I don't think its neccessarily that proposals lack visibility. I'm new at this whole PEAR thing, so it could just be my lack of experience and I guess I was just expecting faster/more verbose responses.

With a package like Math_Polynomial its a bit harder to get attention since many of use won't be using it, and so don't care all that much about it.

To me, one of the highlights of open-source is generally quick development time for individual pieces of a project ( ie PEAR packages ): at work I can expect feedback regarding a component of whatever within a week, despite having to have everything go through layers and layers of people. I guess for a small PEAR package to sit for weeks or months without feedback seems... slow to me.

A couple weeks seems like a long enough wait for me, but it might have been good to send out a couple emails askings for feedback before moving to voting.

I guess another thing that's thrown me a bit is that the whole process seems a bit bureaucratic. I can't find any reasoning behind some of the coding standards ( discussion on the list about using '||' vs. 'or' and 'if (...) {' as opposed to 'if (...) [\newline] {' seems a bit ridiculous to me... the code is readable and maintainable either way, let developers have some freedom... ) and it seems wierd that commenting and revising proposals during the voting phase is not possible ( How can we respond to and possibly fix things you're commenting on if we can't edit the proposal...? ) Yes thins are burearucratic, some people who are involved in PEAR like to be pendantic, thats part of OSS too I guess.

I guess the last bit is I was just under the impression that the voting process was more to say: "Yes, continue to develop this towards a release" rather than "Yes, we like what you have as a final package." I was lead to believe this by statements like this in the manual: "Registering does not mean that you are going to release a first version of your package. It just means that some basic information about the package will be added to the PEAR package database."

I would agree with you, except we've got burned in the paste with people starting a project never getting it to usable point, and then being a pain when someone else tried to get a similar PEAR package in place. So most proposals are at least ready for an alpha release at the proposal time. That being said you code looks far enough along to get accepted, Its not a requirement that every feature is in before exceptance, just that you show you're willing to listen to feature requests.

As such, it seems strange to me that I'd get voted with 0s because of coding style issues ( which are trivial to fix, and could be fixed before a release if they really need to be ). But hey, whatever, vote for/against the package and whatever happens happens. Some people are a pain about coding style issues, they review that instead of design or code. Not much anyone can do about that except live with it.

- Keith

I'll take a look at the code and give it a vote. -josh