On 1/29/07, William Hamilton <[EMAIL PROTECTED]> wrote: > Chris Travers wrote: > <SNIP> > > This certainly has come up in the past. I am not sure we have a > > complete idea of how this is going to work yet. I think we want to > > get more of our own infrastructure developed and tested before opening > > it up to other sub-projects, however. I suspect that the next step > > will probably to move the public email lists onto our own servers. > I do not see the benefits of moving list in this manner, it creates a > reliance on certain members of the core team. If this is to continue to > be a fully open development project these types of reliances should be > at a minimum. Google groups or the current sourceforge lists (I now SF > has some issues) should be sufficient.
This discussion started after the Gmail/Sourceforge issues a while back. It has been a low priority. But one advantage to moving it in-house would be more control over mailman configuration, etc. Right now, infrastructure development is taking much higher priority over infrastructure expansion (look at how long it took us to install Drupal). We already have the core list on our own servers but that isnt the same thing as manageing the other three lists.... > > > And we need to get our community CMS better developed. And we still > > don't have a public demo up yet. > Do you just mean more content or a new CMS? Making sure it meets peoples' needs, more content, moving away from the Drupal theme, etc. > If the APIs etc are defined well enough then external products can be > developed discretely. For an example check out a CMS I do a lot of work > with http://plone.org/products/ hundreds of products developed > independant of core. I would prefer a closer build relationship with > developers rather than creating the wheel each time but reliance on the > core developers means less core product development? Agreed. Eventually, I would like to see a documented (and fairly stable) API existing in the following areas: 1) Physical storage (for custom triggers) 2) Model Access (stored proceedures) 3) Perl modules 4) Web services At least a couple areas of the software (customer/contact management) will feature these things in 1.3, but they may not be completely stable for another release or two. > Could we look at introducing teams to work on certain aspects. At the > moment I see us relying on the core team for technical development, > system maintenance (offerings such as http://code.google.com/ could > offload some of this burden), direction and vision, training support.. > all the stuff a project like this needs. If I may say so, I think the purpose of the core team is to direct core infrastructure and make final decisions about direction and vision. While it is important in these areas to see what the community thinks is necessary, this is sort of the role that the team has. However, I do agree that we are too core-centric at the moment. This is largely because there isn't a huge degree of community assistance in most of these areas at the moment. I have been trying to encourage two things in this regard: 1) Community-maintained infrastructure (i.e. unofficial wikis, documentation, companion projects, how-to's and the like hosted outside the core infrastructure) and 2) Community involvement in technical work. Note that most, though not all, of the patches supplied by the community have been accepted. These areas not only create a larger, more viable community which is less dependant on Core, but also make that community more visible, which is good for everyone. > > Is it a viable option to break out into key areas such as marking, > technical, infrastructure, documentation etc. There will be overlaps in > resources but this could allow a buinessperson with a marketing > background, or an accounts person who likes to write documentation a > great opportunity to get involved. If anyone wants to get involved *in any way* please let us know how you want to help. We are here to help you get involved! > > Just my 2c worth. > > Just to add, I have not yet migrated over to LSMB but willing to provide > assistance where I can. I am not a Perl developer but have fiddled with > LaTeX templates and can write good england sometimes. Happy to work > with technical people and translate into normal speak. > If you are interested in getting involved in the documentation, have you looked through our manual? If you are interested in helping out, that might be a good place given what you say. Currently, it is still mostly applicable to SQL-Ledger too :-) Best Wishes, Chris Travers ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
