> a) Announcing features and changes that are either to be implemented > or to be merged on list. This would give the other developers a heads > up that certain areas of the code may see changes here and there. In > addition, those interested get the ability to keep on eye on the
+1, though sometimes it's tough so this should be a goal and not a requirement > b) More complex features need documentation anyway, which leads to > the idea (brought up by Josh quite some time ago) that these features > should be described with their objectives and implementation proposal > on a wiki page. This page would then be transformed into feature For complex features, yes. +1 > c) After code has been checked in, a code review should be opened > and made available to interested developers, maybe as part of an > announcement on list. This would serve a couple of purposes: 1. code > quality is likely to be increased. 2. developers would be informed +100 It's something we are doing with our features and I think it works well. Even if it takes time to get a review done, starting them is important. Chris -- Christopher Brooks, BSc, MSc ARIES Laboratory, University of Saskatchewan Web: http://www.cs.usask.ca/~cab938 Phone: 1.306.966.1442 Mail: Advanced Research in Intelligent Educational Systems Laboratory Department of Computer Science University of Saskatchewan 176 Thorvaldson Building 110 Science Place Saskatoon, SK S7N 5C9 _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
