Proposals 11 ‣ Light enough / heavy enough ‣ Public and open for comment ‣ Standardized formats ‣ Archives ‣ Non-trivial review Wednesday, December 17, 14
proposing major new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Python. The PEP author is responsible for building consensus within the community and documenting dissenting opinions." PEP-0001 http://creativecommons.org/licenses/by/3.0/ Tendenci Open Source Developers at Schipul Wednesday, December 17, 14
‣ Pre-PEP discussion on mailing list ‣ Rejected PEPs are retained ‣ PEPs are publicly accessible and discussed ‣ Reference implementation often required Details of PEPs 20 Wednesday, December 17, 14
evolves Java™ technology specifications using the Java Community Process (JCP.) The JCP produces high- quality specifications using an inclusive, consensus-based approach that produces a Specification, a Reference Implementation (to prove the Specification can be implemented,) and a Technology Compatibility Kit (a suite of tests, tools, and documentation that is used to test implementations for compliance with the Specification.) Experience has shown that the best way to produce a technology specification is to gather a group of industry experts who have a deep understanding of the technology in question and for a strong technical lead work with that group to create a first draft. Agreement on the form and content of the draft is then built using an iterative process that allows an ever-widening audience to review and comment on the document. Java Community Process 2.9 Wednesday, December 17, 14
draft written by committee ‣ Much heavier than PEPs • But that's by necessity! ‣ Membership is required • But it's free for individuals Wednesday, December 17, 14
is straightforward: a specification undergoes a period of development and several iterations of review by the Internet community and revision based upon experience, is adopted as a Standard by the appropriate body... and is published. In practice, the process is more complicated, due to (1) the difficulty of creating specifications of high technical quality; (2) the need to consider the interests of all of the affected parties; (3) the importance of establishing widespread community consensus; and (4) the difficulty of evaluating the utility of a particular specification for the Internet community. RFC 2026 Wednesday, December 17, 14
published through well-known shared directory ‣ Discussions happen in various venues • Archives of discussions are required ‣ Established "maturity levels" through which RFCs pass ‣ Archives of all RFCs are maintained Wednesday, December 17, 14
(Word) ‣ Archived on central file server ‣ Mail list discussions ‣ Discussion meetings • Representatives from other groups / areas • Everyone welcome Wednesday, December 17, 14
Designed to promote accessibility and adoption ‣ Simple text files / restructured text ‣ Discussions on mailing lists, in meetings, and in review tools Wednesday, December 17, 14
and archive ‣ gerrit Results: ‣ Over 100 detailed, reviewed design documents ‣ Archive of discussions and decisions ‣ Broad understanding of why and how the system was being constructed 30 Wednesday, December 17, 14
Bell Labs 33 Synergy Education Deadline Teams find faults better than individuals Competition Meetings tend to find false-positives Process Less-experienced learn from more-experienced “Education by observation” is not very effective Meetings impose a schedule Deadlines can be imposed without meetings Egos give incentives to contribute/improve Competition can be achieved without meetings “Inspections are part of official process.” Facts, not tradition, should determine process Meetings No Meetings Wednesday, December 17, 14
vs. individuals for code reviews Largely confirmed Votta’s findings. Reading Meeting 1.7 defects/hr. 1.2 defects/hr. Reading is 50% more efficient Wednesday, December 17, 14
from reviews 39 Hewlett-Packard AT&T Bell Labs Bell Northern Research IBM Error-detection cost reduced by a factor of 10. 10-fold quality improvement. 14% productivity increase. Prevented 33 hours of maintenance per defect discovered. 2-4x speed detection- time improvement versus testing. 1 hour of inspection saved 20 hours of testing and 82 hours of rework (if defect had made it to customers.) Maintenance cost for inspected programs was 1/10th of that for uninspected programs. Imperial Chemical 10:1 ROI, saving $21.4 million per year. 3% project effort in inspections reduced testing defects by 30%. Design and code inspections cut integration effort in half. Litton Data Systems Wednesday, December 17, 14
Upstream inspection is powerful 40 "Bellcore found that 44 percent of all bugs were due to defects in requirements and design reaching the programmers." Tom Gilb, Optimizing Software Inspections Programmers can do whatever you ask them to do! Wednesday, December 17, 14
detect up to 90% of the errors in a software product before any test cases have been run. And that signifies an extremely effective process." Robert Glass 42 Wednesday, December 17, 14
is less than the cost of the testing that would be necessary to find the same errors. What we have here is an effective process that is also cost-effective. And that’s a pretty nice combination. Robert Glass Wednesday, December 17, 14
abingham
.jpeg){kind=avatar}
ostk0069
tama50505
philipschwarz
kotamanegi
orgachem
okashoi
datanalyticslabo
tanakahisateru
sgash708
saitolume
maroon1st
dropout009
davidbonilla
maggiecrowley
chrisshort
garrettdimon
skipperchong
mojombo
jakevdp
lara
marcduiker
sonatard
reverentgeek
smashingmag
