@Edwin Thank you for your positive feedback Edwin. That is highly appreciated.
> Also, it is unclear what level of support can be expected of a particular > widget. I think we could be clearer about this. It would be great if we > could clearly identify on the web site a 'lead' for each widget. And if no > such lead exists for a given widget, we could indicate that the widget is > supported on a best-effort basis by the Nebula community. This would help > set expectations for users and widget maintainers. > We have identified this [1]. As it currently stands, the set of "Release" widgets is actively maintained and the set of "Incubation" widgets are either new or unsupported. However, even with commitment from the widget authors, in general, response to bugs is not satisfying [2]. So now I'm going to suggest something radical, but that is a direct > consequence of your observation that there is no "us". I would suggest > splitting all of the Nebula widgets into separate subprojects and keeping > Nebula as a top-level aggregator project. I think the 'benefit' of trying > to reduce overhead by lumping all our widgets together is actually a major > hindrance and causes too much confusion, unnecessary interdependence, and - > crucially - loss of accountability. At the very least, we could split out a > 'Nebula Miscellaneous Widgets' subproject from the top-level Nebula > project. But I think it would be better if each widget that has a clear > owner to have its own subproject. > Unfortunately, the accountability is a major problem in open source projects where people come and go, but are frequently not replaced. (a variant of the "tragedy of the commons" [3]). Splitting it further is a good idea but you should not underestimate the benefits of having an aggregated project and you should also not overestimate the matter of accountability (again [2]). I am actually pretty content with the current model where new widgets can be integrated real quick and released for consumption within a couple of minutes. If we take for example NatTable. I am very happy with the way you guys manage it. The project is running very smoothly on it's own but it is loosely coupled to Nebula. Some of the aspects that set NatTable apart from any of the other widgets are that it has more than one committer, it has it's own source repository and build and it is considerably larger then most Nebula widgets. However, integrating NatTable in a common Nebula repository has not been realized because it is not easy to do. So how could we implement what you suggest but still be agile, management-wise. Regards, Wim [1] http://wiki.eclipse.org/Nebula/restructure#Proposed_widgets [2] https://bugs.eclipse.org/bugs/buglist.cgi?list_id=5017871&classification=Technology&chfieldto=Now&query_format=advanced&chfield=%5BBug%20creation%5D&chfieldfrom=2012-04-01&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&component=BidiLayout&component=CalendarCombo&component=CDateTime&component=CollapsibleButtons&component=CompositeTable&component=Core&component=CTableTree&component=CTree&component=DateChooser&component=FormattedText&component=Gallery&component=GanttChart&component=GeoMap&component=Grid&component=Oscilloscope&component=PaginationControl&component=PaperClips&component=PGroup&component=PictureControl&component=PShelf&component=RadioGroup&component=releng&component=RichText&component=STW&component=TableCombo&component=Treemapper&component=XViewer&product=Nebula [3] http://en.wikipedia.org/wiki/Tragedy_of_the_commons
_______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
