hello all...

[jsWalter]

I thoroughly enjoyed reading the historical thread on this. Thanks
Brandon. I'm sorry to see that your (Brandon) messages where not among
them. Someone could take the view you didn't participate; which I know
is not true.

I was glad to see Brain and Aaron chime in in this; "this" being the
take-up of XRMS, again. This is not the first time this topic has been
discussed, and I don't think it will be the last.

I see (almost) the same bunch talking as about this, as in the past.
This is not a bad thing, as history and an understanding of the past
is a good thing.

As someone mentioned (off line) this group is a bit light on actual
developers, seems to be more a of "users" level group. I guess, thus
the name of the Google Group. ;)

As some of you may know, I've been involved with XRMS, at various
levels and intensities for a few years now. A core piece or 2 is mine.
Segment fixes and updates, etc. But I have not touched it in a while
now; for any reasons, mostly economic.

There has been discussion of a new "lead", someone to receive the
'baton' from Brian and help the project grow and succeeded. Brian has
been excellent in this capacity, but he has other obligations and
priorities.

I can think of 2 or 3 people on and off this group who could fill this
role. Whomever it ends up being, it needs to be someone with
development and team leading experience. Everyone has talents that can
be brought to bear on this project, but not everyone can, or wants to
be lead.

As to an XRMS wiki; one exists, it has been announced and no one has
mentioned it or really used it. It has had next to no traffic. I would
really like to see someone step up and take this wiki and finish what
I started. I did it just to see if it could be done and in what form
it should take.

http://torresgroup.us/xrms-wiki/doku.php

If someone wants to contribute, log into it, make yourself an account
and start editing. I will insist that the structure be maintained. As
for the skin? I'm not married to it. It works and looks OK, but it
could be better. If anyone can make or modify a dokuwiki skin have at
it, send it to me and I'll stick it on! Also, I will be making a cron
job that will tar ball the entire wiki for anyone to download at
anytime. I don't want to fork this either, so, if you pull the tar
ball down, use it for yourself but please don't publish it; make real
changes on the original. Once "we" get a real site going, I will move
the wiki to that site and go from there.

Speaking for forking. No!

Oh, I hope I wasn't too ambiguous on my feelings on this topic.
Forking is not a good idea. Forking can kill a great project faster
then ignoring it.

Leadership:
1) Leadership is assumed in dynamics like this. Someone steps up
does work, gives ideas offers suggestions contributes code. Slowly
others follow.

2) Leadership actually is "anointed", in groups like this. We have
an established leadership; people are willing and have stepped up to
do things with and for the project. If the current leadership does not
share or release their control to someone, than actions by others
aren't going to work. Existing leadership need to see who is doing
what and how committed they seems and then decide if they wish to
share/release control with/to them.

I have been told several times that Leadership is assumed, not
anointed. This is only the case when there is not a clear indication
of current leadership. If there is current leadership, then new
leadership is anointed; because as long as the original leaders are
around, many will look to them for the OK before anything is really
done. This doesn't help anyone or the project.

Democracy:
Well, this is a good idea in general, but not in detailed practice.
Not everything needs to be voted on. That is one way to insure a
project grids to a halt. The leadership has to lead, that means make
decisions, sometime unilaterally. If the membership disagrees, they
will/should let the leadership know. If enough disagree, that action
can be changed. If not, the group will lose members, but any given
group will lose members any given time on just about any given topic.
I have ran a few Yahoo groups with membership upwards of several
hundred people. You can please everyone, you can only take things in
the direction you feel things need to go, if enough disagree, you
either yield or some leave, or you step down. That's group dynamics on
the net.

Take the XRMS wiki for example: No one stepped up, it has been
discussed in length, to decided it was time, made the first stab at
it, designed its structure and offered it to the community. No one
picked it up. It still sits there. Now we have someone offering to run
with it, but the make no mention of the existing work.

I think this wiki can be hosted on sourceforge, but not having an
admin account I can't tell you for sure. Baring that, it can live on
my service and we can make link (or the SF admin can) to my site and
go from there.

CMS:
Drupal? Why? XRMS has a small CMS built into it and XRMS.org uses it
right now. What does an XRMS "marketing" effort really need and do we
really need something a huge as Drupal to accomplish it?

Lets define the marketing effort and issues that we think that are
needed, then we can discuss how to solve them and get where we need to
go.

2.0
Sorry, nope. In my view XRMS is not at 2.0. ready.

XRMS CRM v1.99.2 (2.0rc3) 2006-07-25

If you want to have a stable release, then round up list of items that
are to addressed (fixed), publish that list, set a time line, get
people to step up and fix something and then have a real release.
Maybe 1.99.5, but not 2.0

2.0 should be more than a simple stable release. It need to have real
enhancements; whatever that really means.

And no, we can not have a release in 2 weeks. 2 months maybe, 6 would
be better.


DEV TOOLS
The code stays at sourceforge. It has a history, it has depth. We
might not like some of the tools, but it is an industry standard,
better or worse.

As for mailing list and "boards", Sourceforge has these tools, and
they have a history with the project as well.

It's fine talking a conversation "off-line" (like this one), but once
things are settled, they need to go back to the public forums for
others to see and read.

This group is fine to "clean the laundry", but the real work needs to
be done on the forums.

PROJECT SPEED
Move too fast and people get left behind or feel that they have no
input.
Move too slow and people think the project is dead and they move on.
Thee is no easy answer.

NEXT STEPS
That's easy! This is the order as well..
1) ask for ownership of the xrms.org domain
2) a documentation group needs to be established an begin work, in
earnest
on the wiki
3) a list of "things to fix/correct" need to be created and
prioritized.
A team of "users" can easily perform this task.
4) A road map created based upon items in #3
5) individuals step up and take items to work on from #3 list

Notice, no time line here. We can't have a time line yet. Too many
unknowns and variables. Once the issues are itemized and prioritized
and a road map outlined and items assigned to individuals, then the
individuals need to commit to a time frame for completion. Once times
are agreed/committed, then a time line and release date can be issued.
Not before.

This whole thing might take 6 months before we are agree to issue a
release date.

I know, no one wants to hear this.

I see that someone has already created a list of "Project
Responsibilities" and attached a few names to some of these areas.
Notice the glaring hole?

He's laid out a nice project, lined up everything nice and neat, but
there isn't anyone to do that actual underlying work. Without
developers to actually fix things, this is going no where.

Yes, Aaron said he could assist, a bit, but he's busy. I wouldn't even
think to ask Brian, he has bigger fish to fry!

That's my 2 cents.

Walter