On Tue, Jul 6, 2010 at 5:18 AM, Buchan Milne <user-9b139aff4dec@xymon.invalid> wrote:
On Tuesday, 6 July 2010 07:08:15 Neil Franken wrote:
Hi All
Please, let's keep development discussions *only* on the developers list. If
people interested in this are not on the developers list, they should join it.
Unnecessary cross-posting between a development and a support list usually
compromises one ...
The list for
Volunteers(http://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Dev
eloper_Guide#Xymon_volunteers_Roles_and_Responsiblity) should be closed
for now.
I personally don't agree with the layout and some of the content of these
"books" (IMHO, they are very biased to the way T.J. uses Xymon), and I see no
reason that it should be outside of the Xymon project. I would prefer that the
non-biased content on it be migrated into the Xymon project (wherever it is
hosted). SF offers Mediawiki (among other software), so it should be easy in
future to migrate the content, once we are in a position to enable Mediawiki
on SF.
Same here, I think xymon should have book type of xymon docs beside
existing RTFM.
The contents on current xymon wiki(using mediawiki) is just front end
content collector.
Doesn't mean it need to taken chapter by chapter to roll into final book.
If you are not on the list you can still contribute by testing
and giving feedback.
But, that is a separate activity to development, and can already take place as
is. What we need to focus on at present is development aspects. This should
not pollute the "user" list.
I think for the type of email that related project admin/leaders
discussion, cc to user list is still needed.
Many volunteers(end users/customers of xymon) are not subscribed to
developers list yet.
Right now we need to finalise the structure going
forward. I think TJ hit the nail on the head by suggesting that that we
should see the co-admin as project leaders.
Not necessarily, they are potentially different roles. Good software architects
aren't necessarily good at administration, and vice versa.
Please feel free to modify R1 if modification is feasible. if not,
create another section of yours.
Please share your ideas with us.
tj
OK guys and gals the time
has come for us to put rubber on the road and the only way we will do
this is by getting organized.
I think it would be advisable to have 2-3 Team leads. Maybe we should
break up the teams into geographical area's i.e. The Americas,
Europe/Africa and Asia/Australia. This way the team leader can meet with
their teams(on IRC,Skype etc) during a convenient time in their time
zone. The team leaders can have a weekly meeting to report on progress
and so on. This way only the team leads will have to make some
arrangements around different time zones. Just to be clear I don't want
us to have meetings for hours on end with no outcome.
I agree we should have meeting policy, but use it wisely when email is
not effective.
For specific topics with a specific intended outcome, meetings are fine, but
email discussions are often easier to keep on topic.
I think we need to discuss what the priorities are now, and how we are going
to address them.
What I believe the priorities should be for now:
1)Fixing reported bugs on 4.2.x, and getting a good, stable 4.2.4 out
2)Finalise the feature plan for 4.3.x, document what is missing for a new
4.3.x beta/rc
3)Discuss the current obstacles to adoption of Xymon by more users, and fit
solutions to those obstacles into the 4.4/4.5/4.6 feature plan
4)Address project administration obstacles (e.g. get at least one more SF
project admin added, add svn commit mails, setup various tools available on SF
etc.)
Agree.
However we need to
focus on getting the work done and unless we formalise this now I am
afraid we will just descend into chaos.
We already descended into chaos, let's document the ideas that came out of the
chaos, and move on to do what needs to be done in the immediate future, while
providing a way for people enthusiastic about new features, layouts etc. to
start working on those.
Excuse me for making the mess.
Buchan and Neil are better candidates for project admins, IMHO.
I will read more and post less(not to create more chaos).
and let Neil and Buchan drive the effort to get us there (a better
managed project).
tj
Regards,
Buchan
--
T.J. Yang