Hi Wim,
So how could we implement what you suggest but still be agile,
>> management-wise.
>>
>
Here are a few suggestions:
1. Create separate git repos and hudson builds for each widget. This isn't
a big deal to set up, and it will give freedom to widget maintainers to
focus on their projects without worrying about potentially impacting
unrelated widgets. It will also for easier tagging and branching of
individual widgets.
2. Revamp the widget catalog. This is the first thing prospective users of
Nebula will see, and it should convey accurate and useful information to
them.
a. Indicate who the lead maintainer is for each widget and provide
contact info, or if there is no active maintainer indicate this as well.
It's great that we have identified this already, but we should put this
info into the catalog because it tells users how they can get support.
Users are not going to dig through our wiki to find this info.
b. Provide links to the widget's source repo and ci build (see #1)
c. Provide links to the bugzilla for each widget so users know how to
submit bug reports and maintainers can see what needs to be done.
3. Create separate widget subprojects. This is probably the biggest pain to
deal with administratively, but as far as agility is concerned, I think it
will make us *more* agile because it will allow widgets to be released
independently.
Now I do realize that there are a large number of widgets in Nebula that
see very little active development, so creating separate projects for each
of them may seem like a waste of time. But what it will do is allow us to
release them separately from the widgets that *are* being actively
developed. And anyway project setup is a one-time cost. If a project is set
up and nothing ever happens with it, fine. There's no additional work that
needs to be done. But we never really know when development is going to
start happening for a given widget. This way when it does, we'll be ready.
I think we can easily do at least 1 and 2 in the short term, and I'd be
happy to help doing them. 3 is more work to set up and for individual work
maintainers going forward, but we can have all of the projects operate
similarly and use shared templates and things to minimize the effort
involved here.
Edwin
_______________________________________________
nebula-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/nebula-dev
