Re: [pear-webmaster] PEPR

Hi Aidan Lister! You wrote: >> >There's a couple of features I'd like to see in PEPR >> >- Text_Wiki instead of BBcode (BBcode doesn't seem to work, it's not >> > parsed) >> I'll implement that next, when I have time. Needs some change to the >> database, so you can select to use BBCode (default because of BC) or >> Text_Wiki. Maybe 1-2 weeks. If you like you can provide me a patch. > I can probably do that! *checks timetable* If not, no problem. That's one of the next tasks on my list. :) >> >- Ability to change proposal while in C-F-V, or atleast add comments and >> >reply to the conditional votes >> This is not in sense of the workflow. When going to C4V all issues >> should be solved. > They should, but often (well, not often) interest picks up only once CFV has > been called. You would obviously macerate the complete process with that. Sorry, I will not grant this change untill I'm forced to, by the community. Feel free to create an RFC for that, but IMHO one should rather teach people to really clearify all issues before calling for votes. >> Reply toconditional votes is not feasible. If you have >> conditional votes you need to get a +5, you will have to implement them. > If the changes are implemented, there's no (built in way) of contacting the > author to let them know you've made the changes (sitting on 3 conditional > votes that have all been rectified for PHP_Compat, the same was the case > with Net_GSQ - conditional votes never changed though problem rectified) Add your comments to the release notes. If anyone is complaining, you can refer to that. >> Commenting is only done during proposal phase. > But why! To enforce people to clearify all issues during proposal pahse. During the vote phase everyone should have the same level of information on what he's voring on. Imagine, if 3 people have voted and then some new information raises and they want to change their given votes? This would not be feasible at all. As I said before. Feel free to place an RFC on your issues, if they are that important for you, so the community can aceept a redefinition of the proposal process as it's implemented now. For me it would just b0rke our whole proposal process. >> >- Emails not sent to proposers twice! >> They arn't. They are just send to the proposer and to pear-dev, since >> it's not necessary to be subscribed to pear-dev to propose a package. No >> sense in changing this. > Sorry, I should have been more specific - commenting on your own proposal > will result in two emails sent, both to yourself. Right. One could fix that. Will consider this, when switching to my new mailer class. Thanks for your constructive feedback! Regards, Toby -- Tobias Schlitt a passion for php http://www.schlitt.info