From:
Nathan TorkingtonDate:
October 10, 2000 18:08
Subject:
Now and then
Message ID:
14819.48215.356645.609897@prometheus.frii.comI think we're talking about two different periods of development here. The immediate question facing us is how to structure software design. This is different from the ongoing maintenance of Perl. We want and need a small group to design perl6 correctly. I can't see this working any other way. Software design is a completely different process from maintenance, and it's unrealistic to expect the maintenance model (big open mailing lists, everyone says what they want) to work for an intently cerebral activity. Design I'm seeing as in two parts: architecture (what are the major components we need?) and detailed design (where each component has an API designed and the interactions between components resolved). The architecture will be partially decided by Larry, and seems best done by a few experienced with such things. Detailed design seems appropriate for groups of 5-10 people in each area. In both cases, public viewing of the proceedings is mandatory (you can read their messages and see their thoughts and comment in private). Implementation is different from design, and different again from maintenance. If we do the design, test cases, and stubbing well enough, we could have a cast of thousands doing the implementation. I honestly don't see us arguing over design. Or even over implementation. The big meat of this discussion so far seems to have been how to prevent the ongoing maintenance of Perl from being coopted. I'm thinking about a team structure for ongoing maintenance. Each area (docs, stdlib, interpreter, compiler) has its own team. A team is only a few people: the person responsible for submitting patches, someone responsible for keeping on top of user demands, and someone from QA. In some cases these roles might be shared, and there's no law that says the same QA person couldn't be on several teams. The only law I'd want is that no team could be made up of people from the same company. In addition to these people is a release manager, coordinating with everyone to set realistic deadlines and ensure everyone's talking with everyone else. No release goes out the door until all the teams agree that they have a Good Enough product. This way neither ActiveState, Microsoft, nor the Trilateral Commission can dictate an unrealistic release date. And this goes both ways: if there is a dodgy release, the blame can't be pointed at just one company. At a team perhaps, but there can be no accusations of coercion and manipulation. I don't see voting having a role in any of this, except as a crude opinion poll for the internal equivalent of Marketing. Voting doesn't work in the real world, and in an online world where you can't even make someone respond to your email, I see it being even less effective. How's this sound? NatThread Next
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4