Hey Rüdiger, Those are interesting points. If I may, I'm posting my opinions on them below (I hope others speak their minds too).
- Are we staying with lazy consensus about a new feature is nobody is > answering in a new feature announcement? (3 weekdays) > I like the idea of the "lazy consensus" because most of the people does not answer to every proposal that comes out in the list, and if we are to approve another voting system where we've got to have a majority of *explicit* "yays", then most of the proposals will probably get blocked. I wonder, however, if we should revisit the 3 weekdays period or not. Three days feels like too short to me (imho it should be 5 days / 1 week), but on the other hand, the bad thing about deadlines is that people tend to ignore them till they are about to finish, so having a longer deadline may or may not encourage a longer discussion about the feature proposed --perhaps people will answer one or two days before the deadline is over and we have the same situation as before. I do not have a definite opinion here, I'm kind of thinking out loud and I'd like to hear your opinions (Rüdiger's and other's) on this. > - Is a majority needed or is any vote against a new feature stopping it? > I like the word "consensus" (and not only because it's Latin and sounds nice in English). I like to think that Matterhorn is not a democracy, but it's *better than* a democracy, in the sense that the decisions are not those that the *majority* wants but those that *all the community* wants. This may slow things a little, but I think we have done so far with the current system and I would leave it as it is. - What happens if nobody is reviewing the new code voluntary? > What if review proposals are posted in the list, and if no one comes out in a X-day period, the proposer is entitled to "forcefully" ask somebody to review their code. I'm asuming here that all the developers are committed to the improvement of Matterhorn, and thus they can not forever refuse to review some peer's work. It's part of the job, and part of the commitment you take when you become... well, "committer". At least that's how I see it. I can also think of a "hall of shame" "motivation" system, where one person can: a) assign a review to one or several people; b) wait for a prefixed (reasonable) deadline; c) publish on list who has reviewed their code and who doesn't. I can see some arguments against this system (namely, somebody marking "reviewed" doesn't necesarily mean they have actually reviewed it), but again, I'm assuming "good will" from the people in the community. > - Is the initial commiter responsible if later on we notice that his code > breaks something? > Absolutely, in my opinion, but it also depends on what one understands by "later on" and if the break comes from a bug in the code submitted or a more complex interaction with the surrounding code. Also, somebody recently pointed out to me that the Agile manifest deprecates anything by the lines of "this area is So-and-So's part" or "I don't do this area of the code; it's John Doe's thing". While I see the difficulty of every developer in Matterhorn knowing *every* part of the code, I also see the advantages or developers being, so to speak "acquainted" with many parts of the code. > - What happens with probably small tasks that are not bugs? For example > upgrading the Atom Feed to the 1.0 version (what I hope will not be too > much to do)? Or adding new unit or integration tests... > I'd say upgrades are features and should be addressed accordingly. One of our problems is that developers sometimes focus mostly in new features and completely miss maintaining the existing ones, or keeping them up-to-date. I say "developers" but I'm including myself in the lot, of course. But upgrading things may potentially break some stuff here and there, and I don't see a good idea doing it when we are in the middle of a QA phase (in general). Re. tests, I'd say that they can be added at any time of the process, both in "development time" and QA time. Perhaps in QA one will discover some aspect of a certain part of the code which remains untested and can create a test for it. Best regards Rubén Pérez TELTEK Video Research www.teltek.es
_______________________________________________ Matterhorn mailing list Matterhorn@opencastproject.org http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email matterhorn-unsubscr...@opencastproject.org _______________________________________________
