Looking docs on a site. QA

Hello PEAR, There can be some misunderstandings in my point of view, but I belive I've made it consistent though a little bit cluttered. http://pear.php.net/pepr/pepr-proposal-show.php?id=60 After reading this text I can't say it there's a right summary: >To summarize the problem >- No QA team = can't claim Quality >- Nobody has defined how the QA team is supposed to work, how it >should be structured and what its rights (karma) are supposed to be. These are not the problems - these are consequences. The problems are: 1. - No operative support for PFC; 2. - Useless stuff in repository; 3. - Long standing bugs / patches / RFE's; 4. - CVS access must be limited; 5. - ...add other here to complete the list.. After reading the QA pages it seems, that the primary objective is to create a QA team which will have access to everything. It isn't clear if that QA is created to support PFC or to control whole PEAR repository? If it is the second issue, then you must first meet a whole bunch of requirements to make everybody happy. For example if you remove a package there must be at least 20% of votes among all developers and about 70% from active only to be present (if the maintainer is agreed, of course). I don't know exact numbers of active and not-so-active developers, so I can't say if that percent is correct. Voting can be held monthly by special mail letter from PEAR community. About karma I believe, that some devs can have trusted relations. Then I for example should be able to provide access to my class only for people who I do like. I've got some karma for them. =) Also smb. can be a very asocial maniac, but if he makes a good coding for himself and hence for whole PEAR community why don't give him more of that karma to do that he like? Urgent bug fixes can be made in a CVS separate branch, so developers can review them when the time permits and release a new, not -QA version. Another issue is that developer can forget about this branch, so a good notification system also must be in a place. As I can see the most of the problems you have are because of poor notification system. That is desirable to my mind: - notifications about changes made by someone to your CVS repository; (if (s)he have a karma or he is from QA or he just commits the patch and you can approve or disapprove it - that means click yes/no on a commit notification). Convenient? =) That needs to be a system, so like every system it must have a model. This is for 4th & 3rd problems. I think that system should be done before. To grant a Quality of service for developers first and only after that for end users. That will prove that QA is a real force what is capable to solve even most complicated tasks and thus win developer's confidence. You need to start with a general support mechanizm for Pear packages. (Do you remember the rules to submit a package to PEAR?) After that you can outline a place for QA so _everyone_ can agree with this. From "Requirements for contributing code": > 5. The contributor ("you") must be willing to provide support for the > package and must be willing to release future versions that at the > very least fix bugs. > If you are not willing to maintain your code over a long period of > time, it makes little sense to contribute it. PEAR is the standard > repository of PHP packages, and this comes with great responsibility. > Maintaining means more than just providing support via the various > mailing lists: >You must be willing to not only fix bugs, but also integrate useful >enhancements contributed by users of your packages, if they fit the >design specifications of your package. You should expect to release >new versions of your package regularly with bug fixes. If you will be >unable to maintain your package for an extended period of time, it is >expected that you will announce this to the PEAR developer mailing >list, and assign another temporary lead maintainer or publicly >document the fact that your package is temporarily unmaintained, and >the approximate date that users can expect to receive support and bug >fixes, if possible. "the approximate date that users can expect to receive support and bug fixes" - can I set this option for my project? >Warning >Code can be removed from PEAR if the lead maintainers are not willing >to maintain the code anymore and if there is no other person that is >willing to take over the maintainership. ..by QA TEAM based on the voting held monthly and announced by special mailing list. More info is <here>. QA TEAM can also... "How the initial members are chosen".. Strange question. I'd like to hear the answer "Any who'd like", but first you need to make it clear that duties the QA Team must live with. There also must be a responsibility even greater than for PFC devs. Voting is not enough. I don't think that limiting the number of people in QA is good. Membership must depend on activity. That's my point of view. If QA member is going on vocation (s)he can set this status to Hibernated. =) There should be some period of lethargy after which QA members are automatically become ordinary members. About voting time frame - it can be 5 days, but generally it is more correct to have a week minimum and determine necessary time frame depending on the status of issue being voted. Notification system is a must. Critical issues should be mailed immediately, package removal status or not-co-critical once per month to collect all possible votes. News about package is about to be deleted must go into it's RSS at the same time with a voting note. QA should be able to release crtitical package fixes with a -QA appendix, so it will not afect release process and have an ability to "hide" (not to delete!) some release until a new version come. In this case developers should get notification about package release being hidden and package page should also clearly state so. And another advice - wait for a precedent before expanding QA freedom and limit others. If a first thing is to provide Quality - use the words Usability, Accessibility at first and Access and Karma at last. I don't like people control other people because I can be one of the first and even less if I'm one of the least. As for the 2/3 votes of existing QA Team for a new member if there is 1/3 against - it is not a TEAM anymore. And that TEAM have a very little chances to make a job done, so consider this too. If there is an active man and he does the job well he can be 8th, 10th or even 100th of a QA TEAM as long as there are enough issues to work with. If there are no issues to resolve then QA karma isn't necessary, so QA TEAM can also only have two or three devs. So why do you need that Q to be resolved by any means? It is not a problem now. Make a precedent first to limit a freedom. And make it happen three times. Three is the magic number. Some core QA team must be voted. How many people are here - it depends on opened issues. I can't see any tracker for that issues. Perhaps smb. should start with it? >Any member of the QA team may call for a vote at any time. All voting >is done on the QA mailinglist. Hmm. That's buggy. Voting should be approved by QA team in order not to annoy developers and require at least 10 voices registered in a pearweb voting system. I still think it is more convenient to receive a separate letter about current votings since sometimes it is not possible to monitor a ML activity. This letter should also include results of a previous votings. All QA actions must be public with a clean reason for each action. I think QA must not be too zealous to work on issues where it really doesn't necessary to interfere or if there are other things to do. =) >If the issue isn't fixed with in two weeks QA will email the >maintainers about the issue (if the bug system won't have auto bug >report notices every X week in the future) and if the problem isn't >fixed within one week from that, QA will send yet another email to the >maintainers and if no answer nor fix to the problem is provided within >one week, all members of the core QA team will get the permission to >modify any file needed to fix that QA issue as well as make a new >release. Again. How'd QA TEAM is going to fix issues if it can't even make bug reporting notices and it doesn't have any tracker system to work with issues. Many questions arise - what for do you need that Power then? To be a QA? To annoy developers and tell they are bad because they aren't fixing their bugs? To mess with others CVS? To block everyone's else right to release a package? I think QA should start with PEAR developers support service. I must admit that a great work is done to build PEAR and it is not a QA TEAM work to be in charge of all of this. I don't QA to be like that even if everyone else will tell me it is necessary. All modification in Orphaned Packages must be on a QA CVS branch. And what to do if I want smb. to buy me a cake before making some major enchancements? Do I have a right to do so? How QA is going to handle this? QA and manual. Definitely! That is the main function of QA to me. QA should not approve stable releases. It should monitor stable releases and make developer know if something is wrong in a release, but it can recommend to developers to ask for testing a package. The only exception is PFC. QA should be as polite as possible and annoy developers only if there's an absolute necessity. It is not a regulating/controlling team - it is Quality Assurance. >Notes: >The QA team must always inform the current lead maintainers of any >changes that are done to a given package using the currently configured >email addresses on pear web. ...must always inform about changes they are going to do. Information about what is done must be sent to developers automatically including pearweb and CVS changes (tunable). Repeating once more that QA must release it's own package which will be listed as "latest" packagename-version-QA.ext on a package pearweb page. Full access to QA can be granted only if public status of every action done will be preserved. I can't trust QA programmers which can't write a tracker for AQ. =) > the core QA team will get more permission to fix issues and make release > of packages if reported problems are not fixed in a specific time frame Only in PFC. In other packages only if lead is agreed or QA is lead. CVS should be done on a QA branch. > the core QA team assumes lead over orphaned packages Only PFC. In other packages four months or more of developers inactivity if there are bug standing isssues or his agreement. You can't claim the authorship if a developer is on vacation. Release a QA, but don't mess with others who made a great thing by contributing his code to the world. It is not yours. Do you a have a precedent? Explain it and make a vote. > the core QA team gets the rights to delete releases of packages if > it determines that the release has severe issues "hide" release or make -QA version of it temporary >the QA team is allowed to add QA related notes to package homepages > QA team needs to approve an first stable release for a given major > version number (done by votes) Only for PFC. For others - Never. If you will not have time to monitor that releases you will not have it to test and make a wise decision. That will delay a release and make the releasing process too bureaucratic. Bureaucracy is that makes the bad people "good". >the entire QA team will identify QA problems, will help writing QA > related documents, will help people resolve their QA problems and > such things That's a good thing! And must be the first point to address! Will HELP, but not dictate. >More focus is needed on writing QA related things in the manual and > make then more visible +1 >Make a little QA corner at pear.php.net so QA is more visible for >people and package devs are more aware of the QA team and how it works. +1 Another main point. >keep track of what QA does regarding packages that QA doesn't have >permission to edit through a wiki of some sort Tracker. ..QA does regarding every package. Don't think about Quality Assurance like of a sugar work. It is the work that reqires most Quality. >Actions Required if accepted. >----------------------------- >Forming of the QA team, electing the persons who should for the core of >the QA team. >Giving the core dudes full CVS karma on the pear CVS module, as well as > full access rights to package management part of pear web Make more flexible karma regulating and trust system among package developers. Make QA tracker. Make notification system. Make voting system. That will improve the quality of developers support a lot and will ease the tasks for QA. >Make that little QA pear page >Improve the QA manual pages >Discovering which packages' lead(s) allow QA to help keeping their > package QA approved Make an option somewhere in package management system. >Better coordination of the work which is done, who is going to do > what. Know in advance who is going to write some more entries to > the manual and so on. Tracker. >Make a wiki page of some sort for the info tracking regarding QA > editing package that QA doesn't have permission to edit. Do something. -- TiP, unemployed maniac asocial =)