Email thread
Brendon Baumgartner
starting date. It's quite long, but if anyone wants to read it and see
how this all came about...
========================================================================
======
2/4/09
Brian-
There has been discussion in the XRMS.sf.net forums about revitalizing.
What's your stand on this and commitment level?
You've done great work and I think a system needs to be put in place to
further grow the project. I think everyone currently feels constrained.
Anyway, someone needs to be in charge and I'm hoping you can either find
that someone or take a back-seat and oversee things as something else
develops.
Please let us know!
-Brendon
========================================================================
======
Just FYI I'm all for this, and I'll happily support anyone who wants to
take over this project, if Brian isn't interested or lacks the
time/energy. I have little bandwidth for coding on it at the moment but
would be interested in offering recommendations for future development
and backward compatibility. I know XRMS has a lot of potential and it
could be seriously benefited by some consolidation of its UI,
improvements to its underlying API, and the addition of a solid web
services layer for intercommunication with other systems.
Cheers,
-Aaron
========================================================================
======
At the risk of sounding aolish, me too. I have offered - and the offer
stands - to make available a mailing list for XRMS. I've also been doing
a (very little) coding recently to add lead conversion measurement to
XRMS, but I've not submitted any code yet.
This is timely. Last weekend I spent about three hours reviewing all the
other Open Source CRM systems I could find with a view to migrating
away from XRMS; I couldn't find anything I wanted to move to.
That was almost depressing because I'd reached the conclusion that XRMS
wasn't going anywhere.
All the developers I've spoken with in the past have been very
supportive and helpful. Please don't let us down now! Let's get XRMS
back on the development track.
Keith
========================================================================
======
First let me say that I have had some very thoughtful and in-depth
correspondence with Brian from my first attempt and I think he wants to
gear things up again, so I am not sure things have to be to aggressive.
He seems to be ready to move the project forward.
I really like the product and am happy to get involved with time, money,
and I can provide hosting for the web site, including setup, management,
etc. I can head up marketing for the project(I have 23 years of B2B/tech
marketing experience as well as Product Management), handle copy, etc.
In addition, I have some ideas for revenue models for the product that
might benefit members of the community.
I am available next week for further discussion.
Thanks,
Brad Nickel
========================================================================
======
Hi, Everyone!
Thank you for including me in this discussion! And I want to apologize
in advance if I am going to stir this up to high heavens. I have
traditionally been the shit-disturber around here so I will take the
risk of being that again.
I have now reached a point where, much like Keith and others, unless
something seriously changes, I need to either walk away from XRMS or...
well, I will say it: "Fork it!". Yes, I said the "F" word. It was said
before and at the time it seemed like we had some consensus to avoid the
ugliness. However, under the present status quo, it is starting to look
more and more as a viable route to pursue which speaks oodles to the
amount of frustration built in the community.
Walking away from XRMS does not make sense to me either, considering
what the alternative CRM projects can offer. XRMS is a brilliant system
and I would like to thank everyone and ESPECIALLY BRIAN for all of their
contributions to it. However, we need some fingers at the keyboards,
infusing life into it and to do that, the bottlenecks to marketing XRMS
as a viable project and for rapid new code deployment have to be
addressed. Further delays will only make a comeback more difficult.
Finally, in terms of programming or even administration, I am personally
more or less a dweeb. I am certain there are much worthier developers
who could take the flag out there but, if it comes down to no one
wanting to be the black sheep, I'll happily step up to the scourge.
Thank you all and, again, accept my apologies for being rudely blunt. I
did not mean to hurt anyone's feelings, just say things as I see them.
Best regards to all!
Ivaylo
========================================================================
======
Hi Everybody!
As you might know, i have no remarkable coding skills, but i can help
with hosting etc. But please yes, XRMS needs to go forward. There is no
other option that even comes close to it.
But really, i cant do much but giving ideas how to improve, i am not
that good at coding yet.
Sorry and regards,
Ra Breemen
========================================================================
======
Sorry I'm a bit late getting back to everybody. I've been reading my
personal mail from my phone, and it's not convenient to post a long
reply from a phone.
Brendon Baumgartner wrote:
> Brian-
>
> There has been discussion in the XRMS.sf.net forums about
revitalizing.
> What's your stand on this and commitment level?
I would totally support efforts to revitalize the project, but that
takes commitment of CODE or money, not just enthusiasm.
> You've done great work and I think a system needs to be put in place
> to further grow the project. I think everyone currently feels
constrained.
I have never stopped any developer on the XRMS project from contributing
code, and have done everything in my power to encourage people to
contribute. As I think everyone on this distribution list is aware, I
answer questions when asked, and suggest where and how in the code the
goals of the individual might be met.
In the recent discussion about forking XRMS, I suggested that the
parties involved post their source code control system somewhere so that
the developers of XRMS could review it. Unfortunately, that code is not
in version control, and isn't posted anywhere except on a production web
server. That's not a contribution, it's sloppy development work. If
anyone else has the time to reopen that line of communication and do the
difficult process of creating and evaluating diff's. they are certainly
welcome to do so.
Neil has suggested starting a mailing list. As I said when that topic
was first brought up, I do not oppose it, and we can easily set up a
mailing list on Sourceforge for the project.
Multiple people have told me that they were going to prepare a new
release of XRMS, but that release tarball and documentation has never
materialized. I think that any revitalization of the project would need
to start with at least a snapshot release.
> Anyway, someone needs to be in charge and I'm hoping you can either
> find that someone or take a back-seat and oversee things as something
> else develops.
I believe that I have been taking a back seat for the last couple of
years due to other work commitments, and I don't think I've been shy in
saying that publicly. I am perfectly willing to continue in that
capacity, and as I've said on multiple occasions. I'm also willing to
share or cede leadership when a proven contributor wants to share
leadership of the project. I'm all for it.
While there has been much talk of a new leader, I strongly believe
that that leader needs to actually contribute, not just speak
enthusiastically. I believe that leaders emerge, and are not anointed.
If someone wants to volunteer to be the "development lead" (a title I
have never claimed with this project), then by all means let's talk
about it, agree on the person who wants the title, and let them get to
work with new directions for the code. I would be perfectly happy in a
back seat advisory role.
I want to see XRMS continue to grow and evolve. I am comfortable with
my role in the project changing over time, as it has for all the years
this project has been in existence, and as I am sure it will continue
to.
Regards,
- Brian
========================================================================
======
Hi Brian
> Neil has suggested starting a mailing list. As I said when that topic
> was first brought up, I do not oppose it, and we can easily set up a
> mailing list on Sourceforge for the project.
Not sure who Neil is, but I certainly suggested that (possibly in
addition to Neil). I also offered to host it.
I would be happy with a "real" mailing list being hosted anywhere; my
concern with the Sourceforge lists as they currently are concern
replying (I have to log into SF to reply, which essentially means I
don't
contribute) and searching (not SF's strong point). If those problems can
be fixed then let's make that happen with SF. If the reality is that a
Mailman list would be a better option, which I believe it would, then
I'm happy to set it up. I do not want to set up a mailing list as a fork
of the existing list, so if I'm to do so, I really want you, Brian, as
project leader, to say that you are happy for it to happen and for the
existing lists to be closed down (or made read-only if that's possible).
Keith
========================================================================
======
Hi, Brian!
Thank you very much for your response! It is great to hear back from
you!
I think the essential issue boils down to a lack of open discussion
about what is happening and what needs to be done and this email thread
is probably the first step in the right direction.
I hope you will understand that, while my response was frustrated, it
was not meant to lay blame. I can fully understand that your other
commitments do not allow you to lead the project full time and, frankly,
I do not know many people who could do that. We all have to put bread
on the table in one way or another and I would defend anyone who may
come under fire because of it.
Recognizing that, what I think needs to happen is to build a team rather
than seek out ONE individual who can do it all. We all have strengths
in one area or another and, if we all pull together, this will happen
and happen beautifully!
1. I know at least one person, a long-term contributor to the
project, who may be willing and is fully capable to package a stable
release of XRMS if they were given the access rights. This is a
critical issue to revitalize the project.
2. Setting up a documentation Wiki is another critical thing. I
myself would happily set it up and help populate it if it was possible
to do it on the Sourceforge site. Alternatively, I would also happily
set it up and host it (and pay for the hosting), as long as it is
recognized as the official documentation channel. I would also be
willing to host a commercial channel website for XRMS where developers
can offer plugins or consulting services for a fee so that there is a
revenue-generating channel to XRMS.
3. Keith mentioned that he would be willing to set up and run the
mailing list. I agree that Sourceforge is inconvenient and any
improvement we can add to that would help ease providing support.
4. I liked Brad Nickel's response suggesting he has ideas how to
monetize the project and would love to hear a lot more about it and,
within reason, I would be glad to contribute time and even some money to
make that happen.
There are people who can do bits and pieces here and there and I am sure
you would be relieved to sit back and just oversee as we plough into it
and just give direction as needed. We will all benefit from it!
In all of the above, at the very least, an approval nod and giving the
appropriate authorization and access rights will be required from you.
While it was me who brought up the "F" word again (not in any way
related to last year's instance), out of respect for the enormous amount
of work and excellent leadership you have contributed to this project,
I, and I am sure everyone in the community feels that way, would prefer
to get the go-ahead from you.
So, if we assume that we will have a multi-person, multi-functional
team, would you be willing to suggest what manner of applying for the
various functions and responsibilities you would be comfortable with?
Thank you again for your patience and understanding!
Regards,
Ivaylo
========================================================================
======
Keith Edmunds wrote:
> Hi Brian
>
>> Neil has suggested starting a mailing list. As I said when that
>> topic was first brought up, I do not oppose it, and we can easily set
>> up a mailing list on Sourceforge for the project.
>
> Not sure who Neil is, but I certainly suggested that (possibly in
> addition to Neil). I also offered to host it.
Neil is another one of the XRMS developers who does not appear to be on
this distribution. Sorry for any confusion.
> I would be happy with a "real" mailing list being hosted anywhere; my
> concern with the Sourceforge lists as they currently are concern
> replying (I have to log into SF to reply, which essentially means I
> don't
> contribute) and searching (not SF's strong point). If those problems
> can be fixed then let's make that happen with SF. If the reality is
> that a Mailman list would be a better option, which I believe it
> would, then I'm happy to set it up. I do not want to set up a mailing
> list as a fork of the existing list, so if I'm to do so, I really want
> you, Brian, as project leader, to say that you are happy for it to
> happen and for the existing lists to be closed down (or made read-only
if that's possible).
Sourceforge's forums have all the problems you've mentioned.
Unfortunately, we can't make the forums read-only from my recollection,
but I will investigate further. I believe that the forums will continue
to be an important part of the XRMS community, but a mailman list would
be a good addition. Sourceforge does allow the ability to set up a
mailman list, and I think we should so that users can get support in the
manner most comfortable for them.
What do we want it to be called? 'xrms-users' ? I can set it up today
if we can agree on a name.
Regards,
- Brian
========================================================================
======
Brendon Baumgartner schrieb am 05.02.2009 19:17:
...
> -Brendon Baumgartner (bre...@netcal.com)
>
> -enthusiasm, hardware/hosting, sysadmin
>
- Stefan Pampel <polyfo...@users.sourceforge.net>
-enthusiasm, ..., devel
> Action Items, Step 1
>
> * Project hosting plans - No other major open source project
> seems to live exclusively on SF.net, and I think others will have
> better access to information if we setup our own. I think one thing is
> for sure, and that is that we need a server for the project. This
> server could host the mailing list, trac, wiki, forums, svn, whatever.
I agree, SF is a kind of inflexible to hold up a agile community. Maybe
SF is a place to track bugs, patches and file releases.
> * Mailing list - I think it's in agreement that a
communication
> mechanism is necessary. I'm also going to assume that this is going
> either be either Mailman or some forum software. This mechanism should
> be setup on the project server if that is the direction things go.
As in other discussions, I also agree with a proper mailing list. An
other thing would be presence on the #xrms channel on freenode. I'm not
the 24/7 online Geek too, but this would improve communication between
developers or other people who wants getting xrms forward or be involved
in any way. Lets see it as a part of the open source culture.
> * Package a new release - It has been awhile since a version
was
> released. Brian, what needs to happen for this task to be completed?
Release, release, please release! Sure, there will be some critical
tasks getting done before make an other release. But maybe it helps to
face them on a list to have a goal (such as the donkey a carrot).
> Action Items, Step 2
>
> * Supporting Software - similarly to hosting plans, what
> software are we using for everything other than the discussed in Step
1.
> This could be anything. Do we need a VoIP server? Asterisk? (kidding,
> I
> think) J
>
> o Wiki / Documentation - Wiki software? Trac, confluence, mediawiki,
> etc.
>
> o Development - trac, svn, JIRA, bugzilla, etc
I think drupal is a tool which covers many of the requirements. Also,
drupal.org is a very good example how to organize a project, from my
point of view. Maybe we find an idea or another there.
An other idea is to think about a procedure to track
users/hosters/companies needs, like the debian popularity contetst
(http://popcon.debian.org/) or as seen in dokuwiki (
http://www.dokuwiki.org/plugin:popularity ), as a 'decision maker' to
focus on most wanted plugins or functions.
And hey, communicate, give feedback! Even it isn't a good one. F.e. I
tried to start a discussion on improving UI by using jquery with an
example with jqsearch plugin. But no feedback, even no "Hey, you're
wrong". Then its hard to make technical or design decisions.
Looking forward! ;)
Stefan Pampel
========================================================================
======
I'm between meetings, so I'll reply quickly to some of the main points.
Apologies for not posting in-line, as I'm in a hurry.
what do we want the mailing list to be called?
xrms.org is owned by Chris Woofter, the original author of XRMS. I
suspect he would surrender it if I asked, which is probably a good idea
in any event, since Sourceforge changed the hosting rules somewhat.
Moving the website, wiki, etc are all fine and necessary ideas. They
do, however, seem secondary to actually getting a new release out.
I'll be happy to coordinate the release process and grant release
technician permissions to any XRMS developer who wants to step up and go
through the process.
I'm very interested in using docuwiki for XRMS's documentation. It has
one major advantage over some of the other wiki systems in being able to
have "official" documentation not be editable by just anyone, but
everyone can comment on every page in a wiki form. XRMS's documentation
has gotten out of date, and a docuwiki install would improve matters.
Walter Torres started setting one up from the existing published XRMS
documentation, I'm sure we could get his files.
I also prefer mailman to SF's lists. Let's try to get control of
xrms.org again so that we can point it to a server of our choosing.
Regards,
- Brian
========================================================================
======
Hello XRMS Community,
I am really excited to see all of this enthusiasm for this product.
Having only recently discovered it myself, I immediately found it to be
a solid solution and one I want to use for myself, clients, and
potentially a new business model.
Would like to provide help/use my 20 years experience with marketing,
strategy, feature planning, interface design, and wherever else I might
be needed.
I host my sites at Media Temple in their grid hosting system, so happy
to pay for and host whatever needs to be hosted if it is needed
including paying for domains, etc.
While not a developer, I do have a strong technical background as well
as a great deal of experience in interface design, etc. and want to be
as active as possible as development proceeds.
Thanks,
Brad Nickel
========================================================================
======
Hi, Everyone!
A few disparate points:
1. Please add Randy to the response chain so he can stay in the
loop. Randy has been a humble but highly productive contributor to XRMS
for years and I, for one, have no doubts about his level of commitment.
2. I am in favour of an external site under the control of the
community. In terms of site organization, I like the way the
Squirrelmail site is organized. If we have an idea what software they
are running, we could model the XRMS site similarly. We should ask for
the domain xrms.org from Chris and setup our site that way. I'd be
willing to throw some money towards hosting if no free hosting can
handle what we need or if no one can offer space on their own servers
for the purpose. If we need a virtual server, I have excellent
experience with linode.com (they are blazingly fast!) but, of course,
with virtual servers, hard drive space is limited.
3. While I may only seem to add lot of P.I.T.A. to the process, I
do have more that I can contribute than just enthusiasm:
* I would embrace the opportunity to be documentation lead for
XRMS if we adopt DokuWiki. I use DokuWiki myself and have experience in
installing, setting it up, including namespace structure, etc. and
overseeing what goes in it.
* I have a fair bit of templating experience (the XRMS blueengine
theme is mine) and can help efforts in this regard. I believe we need
to seriously look at AJAX for the UI and would not mind learning more
about it if we go that way and participate in that development.
* I have fixed bugs in XRMS and am presently quietly and slowly
working on developing a native webmail client for XRMS. I am hoping to
have a "proof of concept" alpha version within a few weeks if life does
not intervene. So, I could add some light development to the process or
at the very least, beta-testing. I could help with testing and bug
fixes towards a stable release as well.
If something needs to be done and falls in the above categories, simply
hit me up.
Cheers,
Ivaylo
========================================================================
======
Hi Everyone,
I believe that as we think about further XRMS development, we ought to
consider the following:
The current XRMS is (relatively) stable, and a snapshot release of CVS
should be considered our latest version. Documentation should be
written with this release in mind, and the website updated to reflect
this new release.
Future development of XRMS should be broken into two separate parts,
potentially as separate branches.
1. Small tweaks, fixes and improvements to the current system. This
would include new themes, any bug fixes and security changes, as well as
small UI updates. These could be released in a semi-automated basis via
a release script on whatever our new webhost is. Commits to this branch
should take current documentation in account (i.e. if a change would
affect the accuracy of documentation, then documentation should be
updated)
2. Large architectural changes to XRMS. This would include changes such
as an AJAX GUI, friendly URLs (ala Drupal), and other improvements to
get XRMS using the latest technologies (I'm thinking about jQuery,
friendly URLs/consolidated menuing system ala Drupal, inline but
stateful/saveable sidebar and front page customization, etc). These
should occur in a separate branch, and have as a goal to stay compatible
with the underlying data model (for upgradeability) but not necessarily
fully compatible with the older XRMS from a UI or even plugin
development standpoint.
Let me know what y'all think of this. I believe it will let us avoid a
real Fork, while still allowing developers the freedom to improve XRMS
past simple tweaks and changes. It will also continue to allow a
community to exist around the product we know and love today.
I'll be happy to assist in the set up of this new branch, and aid
discussion of the possible architectural changes that could be made to
XRMS to allow for this. As the primary developer of the underlying API
as well as the ACL system, I believe I could be of some use here.
Cheers,
-Aaron
========================================================================
======
Thanks for adding me to this discussion.
I am happy to see so many of us wanting to move forward.
I just published most of the bug fixes and updates I have been working
on the last few weeks. In my view there are still some outstanding
issues that need fixed before CVS can be considered stable.
1. When Glenn changed the activities/one.php and moved part of the code
to templates/v1.99.php it broke the javascript for calendars. I have
struggled to make it work the same way it worked before code separation,
but I haven't been successful. On my own systems I have reverted back
to the combined code (pre-template) and it works just fine.
2. While this is not a "bug", I believe many of the variables currently
in vars.php should be moved to the user_preferences table and allow the
user/administrator to set/change them dynamically in the system rather
than a sysadmin setting them in the script (e.g. datetime_format would
be a drop-down). I have this on my to do list, but have not had time to
accomplish it yet.
I need help with item 1 (or I can just revert one.php back to what it
was before templates to fix the bug). I will attempt to move the
variables out of vars.php and into the user_preferences table by the end
of this month. I believe the rest of the fixes can come after the
release.
There are a lot of great ideas in this string, but some of them concern
me. For example, I'm not sure what benefit there is to branching into
two systems. It doubles the work needed to update the two systems with
bug fixes and minor changes that benefit both branches. It seems to me
there should be one XRMS and enhancements to newer technologies be
adapted as plugins so that there isn't a duplication of efforts.
As with any volunteer project, things go stagnant if there isn't a
leader to assign roles and if participants are not taking ownership of
those roles with accountability to the group. There is also a problem
when there are too many chefs in the kitchen with different views about
how to cook the same meal. I think specific tasks need to be assigned
to specific developers so that we don't "walk" over the top of each
other - as has been the case several times the past 12 months. While I
appreciate Brian's confidence to allow me to publish directly to CVS, I
think we're missing an important step by not having a peer review of the
CVS and then a more frequent general release process. I'm sure I'm
guilty of walking over the top of some of you with some of my changes,
and I am certain I have introduced my share of bugs along the way too.
This peer review process would help to remedy some of those problems.
I am personally under a lot of pressure to work on "revenue generating"
projects more than was the case a few months ago, so my contributions to
XRMS have been somewhat sporadic, and I simply can't spend more time
than I am currently. I suspect most of you are in the same situation.
I hope that if Brian is unable to be more active as the project leader,
that one of you can do that for us. I think whomever takes on that role
needs to find out the bandwidth of each developer and assign specific
tasks to us and hold us accountable. I believe the tracking system in
SourceForge is quite sufficient if we simply agree to use it. What I
see missing (in addition to an active leader) is a person to take on the
role of review of CVS and publishing it as a general release.
I look forward to XRMS moving forward, and hope to continue
contributing.
Thanks!
~Randy Martinsen
========================================================================
======
Hi, Everyone!
I hope I have included everyone from the previous discussions on this
thread. With all of the enthusiasm for moving forward, I wanted to try
and summarize and shape what has been discussed so we can have something
actionable, with dates and, possibly with persons responsible. Due to
the lack of a better communication tool I have tried to outline in this
email what I see is the initial path we need to take to revitalize XRMS.
To keep this document coherent for all future discussions, when making
changes, please copy the entire document between the start and end
markers, make the changes you see fit (it would be great to highlight
your changes), add comments and input, etc. and reply by pasting the
modified document in your response. That way we can have a current
collaborative document (in the absence of a wiki) that can help us
understand where we stand and how we can move forward. Feel free to
fill the gaps and make this better!
Cheers,
Ivaylo (aka IT gopher)
========================================================================
======
Goodmorning, from where i'm at that is!
I have an addons i would like to make:
-the CVS is good for tech savvy *nix people and coders, but if we want
to make XRMS much more succesful for the masses, things should be made
easier.
-always have a .zip with the latest version, stable and unstable,
available, for the MS masses :)
-i suggest patches should not only be applied to the CVS, but also the
edited php files should be made available so the user can update the
specific file without going through that CVS routine.
-changes should be documented so the user can even edit the php on his
server/host without replacing his own file, very handy in case of
tailormade installs.
If i was not clear enough, please forgive me, english is not my native
language :)
Ra Lapunga
========================================================================
======
Hi, Everyone!
Just to keep the discussion organized into this one document, I have
tried to integrated what has been said so far into the original
document. I hope I did OK with that. However, for the purposes of
staying on track, I would hope if you don't mind to focus more on
Priorities #1 and #2 - those are the most urgent.
I would also like to thank Randy for nominating me as project lead and I
would happily take on the role but I do have some limitations and I
would like the community to be aware of them in case there is a worthier
candidate willing to step to the plate:
* I lack deepth of technical skills, specifically with PHP and
SQL. I am learning, but, if it came down to tracking down a bug that no
one is willing or able to tackle and somehow the ball ended up in my
court, I am concerned I may fail. In the end, I think project leads get
blamed automatically in this situation even if they are not directly
involved in development. There are many large swaths of XRMS code that
I do not understand and many more essential development concepts that I
am not even aware of and I would hate to be a hindrance to the project
due to lack of knowledge or short-sightedness.
* I have experience managing several projects including some
manned by volunteers only but I have only managed one very small (2
persons who were paid by me, two versions only) software development
project before. I am a good generalist and organizer and I am generally
good with coordinating efforts, helping to arrive at consensus,
articulate goals, give creative ideas and informed feedback and my
enthusiasm is, as noted, in large supply. In all of these aspects, I
would probably be an asset but I am concerned whether I will be able to
perform as well in this new (IT) environment.
* I have minimal experience working with CVS. I have an
understanding of the functionality it provides but I would need help to
achieve even the simplest tasks, especially in the beginning.
* Finally, I think, if Brian is moving away from being the project
leader, we should have at least a relatively democratic way of selecting
one. Oh, I'll take the job, sure, but, maybe: 1. There is a better
candidate willing; 2. The community would rather see someone with a
stronger development background and XRMS knowledge take it on.
* I have written myself in many roles. These are all things that
I can do. At the end of the day, however, I can only give the project
about an hour or two a day so just how much I can do will depend on that
constraint.
Now, getting back to the original discussion, here is the updated
document. In the future, please make your main changes in the document
iself. Comments on the side are fine but I was hoping we can avoid
duplicate work of consolidating the information.
Thank you!
Regards,
Ivaylo
>>>>> START >>>>>
Priority #1 - Stable Release for XRMS
As mentioned, the current CVS of XRMS is probably relatively stable to
move towards a stable release. In my opinion, the best way to
accomplish this is as follows:
1. Set a date for feature freeze for the stable release. After
that date, no new features are to be added to the code destined for a
stable release. If we want to move this along fast, I would suggest Feb
15 to give enough time for developers to contribute any currently that
is not yet in CVS to the destined stable release. (Persons responsible:
community consensus). Are we agreed on this date?
2. On the feature freeze date, branch the CVS code into a "2.0"
(the stable release) and a "dev" branch. Set a date for the stable
release date to give enough time for bug-fixes and code improvements. I
would suggest at least a month for testing and bug fixes, taking us to
Mar 15. (Persons responsible: whoever has CVS branching authority at
Sourceforge, community consensus)
3. During the feature freeze period (e.g. Feb 15 - Mar 15), we
should all focus to make the 2.0 code as stable as possible. The focus
should be on testing and bug fixes for the stable release. Items which
cannot be bug fixed by the release date should be rolled back and tested
to previous, stable code so that we put out the best possible code out
with 2.0, even if a feature or two are missing. (Persons Responsible:
anyone else who wants to sign on here, Ivaylo) Are we agreed on this
date?
4. On the release date, create the stable release tarball and make
it available for download on Sourceforge, announce the release on the
XRMS website and close the 2.0 code branch. (Persons Responsible:
whoever has the necessary authority for the Sourceforge CVS and website)
Priority #2 - Assigning Project Responsibilities
Being a volunteer-driven project, we should try to create roles and have
people volunteer to them. I have already written my name wherever I
thought I could be of help, so please stand up and be counted. Also,
you could add notes about how much time (bandwidth) you can commit to
each effort:
1. Project Lead: currently Brian Peterson
2. Developers:
3. Beta Testers: Ivaylo (limited, some PHP), Ra
4. Documentation: Ivaylo
5. PR and Marketing: Brad Nickel, Ivaylo
6. Webmaster: Brad Nickel, Stefan Pampel (DokuWiki & plugin setup),
Ivaylo
7. UI design: Ivaylo (CSS, some PHP), Ra (CSS)
8. Sponsors: Ivaylo, Ra (limited: hosting)
Priority #3 - Restructuring the Project Toos
What needs to happen here is to discuss and put in place the tools we
need as a community to move the project forward. I have made some
suggestions here but feel free to modify that to what you think makes
more sense:
CVS options
Sourceforge - Unless there are serious reasons to walk away from
Sourceforge, I think CVS should stay where it is. It would be good to
know who has what privileges on CVS.
Bug Tracking options
Sourceforge - Unless there are serious reasons to walk away from
Sourceforge, we can stay where we are.
Patch Tracking options
Sourceforge - Unless there are serious reasons to walk away from
Sourceforge, we can stay where we are.
Mailing List options
Sourceforge - issue is having to be logged in at Sourceforge to respond
to posts. But it is free.
Mailman - it looks like it has to be privately hosted with the attendant
costs
Google Groups - since jQuery was mentioned, I checked out their site and
that is what they use for all their mailing lists; some more research is
needed for an informed decision. But it is free.
Documentation Wiki options
DokuWiki - I have tried at least half a dozen wiki engines and have done
a lot of research and, so far, no wiki engine has been able to offer a
distinct edge over DokuWiki. If it cannot be setup as a Sourceforge
app, it needs to be privately hosted but the requirements are minimal,
can possibly be hosted even on a free hosting account. (2 in favour:
Ivaylo, Stefan Pampel)
Trac - Used by development teams and I don't know more about it except
that it includes a bug/issue tracking engine. I don't know if there is
an advantage of combining the wiki with the bug/issue tracking engine.
Poor wiki engine. If it cannot be setup as a Sourceforge app it
probably needs to be privately hosted (2 against: Ivaylo, Stefan
Pampel)
Marketing Site options
(a CMS for xrms.org)
Wordpress - I forgot about it even though I myself have done templates
and even coded some modifications to it, excellent news engine (2 in
favour: Randy Martinsen, Brad Nickel)
Drupal - it has been a long time since I last looked at Drupal, refresh
my memory here... (2 in favour: Brad Nickel, Randy Martinsen)
Joomla! - a very widely popular CMS with hundreds of plugins, templates,
etc. Can be easily hosted on cheap to free hosts. Can drive you nuts
sometimes, though! (2 against: Brad Nickel, Randy Martinsen)
ModX - I have not used it personally but they pitch it so nicely and
there are tons of rave reviews for it. It won "Most Promising Open
Source CMS" from CMS Awards in 2007. The demo looks very slick, too.
(Ivaylo: I'd love to at least have a good look at it before committing
to something else)
Hosing options
(this will be heavily influenced by the set of Project Tools we choose
so I included it here)
Sourceforge - I do not know enough about what site-building capabilities
Sourceforge offers. The Sourceforge servers are usually quite slow and
I would guess we can only install a limited choice of CMS's.
MediaTemple - don't know much about them but at least one person likes
them (and so does jQuery).
*** community ***- if we are going to pay for hosting, wouldn't someone
from the community who has their own server want to receive that
revenue?
HostGator - I have had long-running experience with them. Decent speed
and support.
*** sponsor webhost *** - I wonder if anyone knows if a webhost that
would host us at a discount since we are an open-source project?
<<<<< END <<<<<
========================================================================
======
Hi Ivaylo (and everyone on this thread)
In case of bugs that no one else is able to tackle, please feel free to
contact me and I'll do my best to assist in these extraordinary
situations. I don't have reliable regular time to devote to the project
for development tasks, but I am familiar with the flow of the code and
the intimate details of the APIs, so I'm happy to try to be the final
resort for buried bugs no one else is able to fix.
I'm fully supportive of anyone who wants to lead this project, and it
seems you've already got a lead on any other potential candidates given
your TODO list creation and project management style.
Cheers,
-Aaron
========================================================================
======
Hi, Everyone!
I may be a bit slower responding on weekends but that is the time I
focus on my family and kids so I hope you will all understand.
I was thinking about what is presently happening with XRMS and, as much
as the energy generated is exciting, I think it is very important that
we do not loose sight of the big picture and forget the principles that
have made XRMS such a wonderful product.
Therefore, I hope you won't mind if I suggest that we temper our
enthusiasm and desire to get things done "yesterday" with the desire to
do things RIGHT. That means EVERYONE in the XRMS community has to have
the opportunity to participate in this process and not just the nucleus
that has formed in this email list. That means the SF XRMS forums. Yes,
I know they are a pain, but we owe it to the community to not keep them
out of the loop.
So, at the cost of pushing everything back by a week or so, I firmly
believe we should put the word out through the SF forums to bring any
people interested in this process in on it and only the swing into
action. That way everyone will have a chance to have their voice heard.
I have a very busy day today but I can promise to all of you that, by
the end of the weekend, I will break this discussion into key points
with their own threads on the SF forums to ensure we keep this coherent.
Then the decision to move to Google Groups will make sense if it is
broadly supported.
To give everyone a chance to be heard and participate, I will also
suggest that we push the stable release timeline back by at least a week
so that we have time to organize well. Democracy is a wonderful thing
but building consensus costs time and I believe it is a small price to
pay for doing what is right. At the same time, I will try to push this
as rapidly as possible so we do not loose momentum.
One last note: While there seems to be some consensus to have me move
things along, I would insist that there be a more formal process of
nominations and voting for a new project lead, if we even need one - we
DO need to hear back from Brian!
So, just so that things move along, I will take on the role temporarily
with full deference to what Brian will say and with the understanding
that I will immediately cede it if Brian or a better supported candidate
steps up. I am only acting the part for now for expediency's sake but I
will consider this temporary depending on what time, the community and
circumstances dictate.
I hope you will not see this as me weighing in with some ideology. I
firmly believe it is the best course of action for the community, XRMS
and, ultimately, all of us. Strange to come from a guy who used the "F"
word, I know, but that is just one of the paradoxes of life, isn't it?
I'll look forward to your responses but, in their absense, I will act
according to the above with the hope I have gleaned the right direction.
Have a wonderful weekend, all!
Best Regards,
Ivaylo
========================================================================
======
> Well Said, Ivaylo.
> I agree completely.
Me too. I'm encouraged by the flurry of activity, but doing things right
is more important than doing them right now.
I'd also like to see Brian take the lead, even if it's only to hand over
to someone else, or ask someone to organise a ballot.
Keith
========================================================================
======
Keith Edmunds schrieb am 07.02.2009 21:47:
>> Well Said, Ivaylo.
>> I agree completely.
>
> Me too. I'm encouraged by the flurry of activity, but doing things
> right is more important than doing them right now.
I also agree.
> *(a CMS for xrms.org)
> Wordpress - I forgot about it even though I myself have done templates
> and even coded some modifications to it, excellent news engine (2 in
favour:
> Randy Martinsen, Brad Nickel)
> Drupal - it has been a long time since I last looked at Drupal,
> refresh my memory here... (2 in favour: Brad Nickel, Randy Martinsen)
Moreover my vote for drupal. I can bring in know how in how to setup and
selecting modules to cover the needs, together with Brad, Randy or
anyone who's interested in.
But more in general, we should look a intermediate way how to do our
votes to make our decisions. A public place on the web with a defined
time window e.g. one week from the announcement until the vote is
closed. Any suggestions?
Later on, hopefully our CMS will provide such as functions.
Personally, I prefer the 'Debian way' to most everything in public.
best regards
Stefan
========================================================================
======
Hi, Everyone!
As you may all be aware, I have now posted an announcement on all three
of Sourceforge's XRMS forums regarding our discussions.
I attempted to restrict response to only choosing the discussion medium
for now and have given it a deadline of Feb 15 (one week). I feel that,
once the selection has been made, we should move the discussion into the
new channel, break it up in votable/discussionable threads and proceed
from there. If Google Groups is selected, we could also use the web
page functionality of Google Groups to summarize the results of our
discussions and votes for a quick overview to newcomers.
You will also notice that I added Nabble to the list of mailing list
options. That was another idea I stole from the jQuery website. They
use both! While they use Google Groups for active discussion, they also
use Nabble to archive the discussions. The advantage - Nabble can be
embedded as an applet inside an HTML page which makes it possible to
simply embed the mailing list archive on the future XRMS site without
overhead of development or storage space. All the more that we can
always add Nabble later on, when we are a bit more organized and archive
the past threads from the mailing list. Neat!
Since our discussions here have been in private, away from the rest of
the XRMS community, I would request, in spite of the inconvenience of
using the Sourceforge forums, that all of us who have participated in
this discussion, to DO respond to the new thread:
http://sourceforge.net/forum/forum.php?forum_id=305409 with your
preferred mailing list option (yes, a revote if we have to call it what
it is, this time in public). On Feb 15 we will announce the selected
channel and we can move forward.
Stefan, to your comment about voting, I think the mailing list can be
used for that. We presently do that with a non-profit organization
where I am part of the Board of Directors, all volunteers. You simply
create a new thread for a vote (we prepend the subject of the thread
with "CAST YOUR VOTE: ..." that details the issue to be voted on and the
deadline. Then everyone simply responds with "In favour", "Against" or
"Vote WIthheld" and can make comments as desired. On the deadline date,
the thread is announced closed, votes are tallied and decision
announced. It may not be fancy but it has worked great for us. Note: I
have re-incoroporated your vote for Drupal below.
Thank you all for your patience but this is the only way I know that we
can bring in the whole community and maintain the democratic principles
that open source stands for!
Have a great evening!
Best Regards,
Ivaylo
Brendon Baumgartner
is here.