Right, I see, thanks for the explanation. Most of my comments are actually in what I call early phases (2) and I was planning to adjust my proposals (or withdraw them :-) based on what answers I get to questions. To me, the examples are there to help illustrate the question, or as a basis for creating questions in a discussion. But I realize this could be made much more clear from my side. I'll switch procedure then and ask questions first (1), and thereafter go directly to (3), as the in-between (2) might be a blurry line. Best regards Mike BJ Hargrave wrote:
> From: Mike Wilson <mike...@hotmail.com> > I sympathize with the idea of having input to specifications > traceable in the bug ticket system. Though, a downside is that this > often in practice kills the discussion. It's an additional space to > watch outside of your normal mailing list flow, you have to register > an additional account to be able to reply, etc. This pattern seems > to be confirmed when looking at the OSGi bugzilla; a typical ticket > only involving the reporter and an OSGi representative. > > From working in several open-source projects my impression is that OSGi is a standards foundation rather than an open source foundation. So when discussion specification-work-in-progress, OSGi needs to make sure we follow proper process for IP capture. This is why we require feedback on RFCs to go through the bugzilla system were the participants in the bug discussion know the IP capture rules and we have it all nicely captured in the bug. This mail list, osgi-dev, is focuses on the use of the currently published specifications and is not intended as a feedback mechanism on specification-work-in-progress. > the following is the sweet spot for where to host design discussions: > > 1) Pure questions about design choices -> mailing list This may be fine for a mail list is the questions are of the "why this way?" variety. But when the get to "you should do it this other way", we have IP flow. > 2) Early phase of design proposal discussions -> mailing list > 3) Late phase of design proposal discussions -> ticket system > 4) Complete design proposals -> ticket system > > My rationale is that (1) and (2) usually contain a number of "why > is" and "what is the reason for" questions that are ill suited to > pile up in a ticket system. Also, these stages are probably the ones > that are of most general interest and may attract other mailing list > subscribers to join the topic. > > So, my experience is that a good process is to start out discussion > on the mailing list. When the question phase is over with and the > proposal starts to stabilize, a project representative either > creates the ticket or asks the reporter to do so. At this time it is > possible to include appropriate mailing list posts in the bug ticket > description. > > Of course, YMMV depending on the traffic volume of the project > mailing list. If you have very high traffic on the list, and high > participation in the ticket system, then your sweet spot for when > switching to the ticket system is probably somewhat earlier. > > So, what's your stance on the best place to discuss (1) - (4) ? In general, I have been fine with discussions in this mail list that avoid direct feedback on the design itself. But your recent mails were clearly feedback on the design (which is quite welcome!) but such feedback needs to be done via the bugzilla system for proper IP capture. (Yeah for IP law...) -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the <http://www.osgi.org/> OSGi Alliance <mailto:hargr...@us.ibm.com> hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
