[POLICY] Streamline Setting+Up+a+New+Podling policy
http://incubator.apache.org/incubation/Incubation_Policy.html#Setting+Up+a+New+Podling falls somewhere between guideance and policy. given that process mistakes have been made (eg. https://issues.apache.org/jira/browse/INFRA-1341) IMHO it would be better to create a guide for this part of the process and streamline this section. a radical patch (below) would strip out all policy. for want of a better name, i've termed this guide 'bootstrap' (creation is already used for another part of the process) but suggestions welcomed. as discussed (http://mail-archives.apache.org/mod_mbox/incubator-general/200712.mbox/[EMAIL PROTECTED]), though the current policy suggests that the mentors should do most of the work this is probably unnecessary since the IPMC has already approved it. so, i'd like to see this bit of policy removed anyway. the current policy lists mandates required infrastructure tasks (mailing lists, repository). i'm not sure that this is needed at all. if it is then it would be better to simply to ask that all proposed resources are created. the other bit is about the project status page. perhaps this does need to be explicitly stated. if so then i think it would be better to create this page as part of the 'creation' part of the process. opinions? - robert Index: site-author/incubation/Incubation_Policy.xml === --- site-author/incubation/Incubation_Policy.xml(revision 607711) +++ site-author/incubation/Incubation_Policy.xml(working copy) @@ -288,30 +288,9 @@ titleSetting Up a New Podling/title p Once a proposal has been a href='#Acceptance+By+Incubator'accepted/a -and the podling a href='#Creation+of+Podling'created/a -a a href='#Mentor'Mentor/a SHOULD initiate the creation of: +and the podling a href='#Creation+of+Podling'created/a, +the a href='#Mentor'Mentors/a SHALL a href='/guides/bootstrap.html'bootstrap/a the podling. /p -ul -lithe a href='#Ongoing+Activities'project status/a page;/li -lithe mailing lists;/li -lithe repository space;/li -/ul -p - Your project's mentors are able to undertake many of the setup - tasks. See notes about how to - a href=http://www.apache.org/dev/reporting-issues.html;request project resources/a - such as new committer accounts and new mailing lists. - (Note that a committer account will not be created - a href=http://www.apache.org/dev/pmc.html#newcommitter;until the - Contributor License Agreement (CLA) has been recorded./a) -/p -p - Your project committers/PPMC members need to become familiar with - the a href=http://www.apache.org/dev/;ASF Infrastructure information/a - and in particular the - a href=http://www.apache.org/dev/#pmc;PMC/a notes. - Also see the a href=../guides/pmc.htmlIncubator PMC Guide/a. - /p /section section id=Ongoing+Activities titleOngoing Activities/title - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java Jabber Server
Greetings Jason and Peter. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Sunday, December 23, 2007 5:03 PM To: general@incubator.apache.org Subject: Re: Java Jabber Server On 23 Dec 07, at 10:29 AM 23 Dec 07, Peter Neubauer wrote: Hi there, On Oct 31, 2007, at 4:42 AM, Jason van Zyl wrote: I have the port to Plexus in a tree and I'm sure alag would be fine with it coming along here. Yes, i got that impression too. Guess Alag has no cycles to spare on this and it seems a Apache IM server would be great. Then, does this relate to the Eclipse Communication Framework somehow (which of course uses OSGi as the underlying component model)? Not sure if ECF has a server, but they most certainly can tie into any existing server infrastructure. ECF does have several plugins and APIs focused on OSGi-based servers. As suggested by Peter, ECF is based upon OSGi/Equinox as underlying runtime/component model. ECF does not yet have a full XMPP server implementation, however. We would happily participate in/contribute to such a project. There are a number of relevant ECF APIs/components...e.g. presence/im, async file transfer, im bot, remote OSGi services, voip call API, IRC, Skype, JMS support, etc: http://wiki.eclipse.org/ECF_API_Docs Most of these APIs can/could be used for implementing an XMPP server...and the dependencies of these APIs and their providers are intentionally as little as possible (i.e. OSGI CDC 1.0/Foundation 1.0) to allow for usage by smaller devices as well as servers. ECF is doing more with server-side usage of Equinox/OSGi, and this obviously fits in quite well with an OSGi+ECF-based XMPP server. Please do let me/us know about any such effort that we could contribute to. The ECF dev mailing list is available at [EMAIL PROTECTED] Regards, Scott ECF Project Lead But this variant of the IM server is set of Plexus components, as they were once a set of Phoenix components. I would be interested in participating in a XMPP project, especially checking out the implications of that for mobile-to-mobile communication and streaming between XMPP peers. /peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLICY] Streamline Setting+Up+a+New+Podling policy
Hi, On Dec 31, 2007, at 5:47 AM, Robert Burrell Donkin wrote: http://incubator.apache.org/incubation/ Incubation_Policy.html#Setting+Up+a+New+Podling falls somewhere between guideance and policy. given that process mistakes have been made (eg. https://issues.apache.org/jira/browse/INFRA-1341) This issue points out that even members of the incubator and members of the foundation aren't always clear on what parts of infrastructure are accessible to whom. IMHO it would be better to create a guide for this part of the process and streamline this section. +1 a radical patch (below) would strip out all policy. for want of a better name, i've termed this guide 'bootstrap' (creation is already used for another part of the process) but suggestions welcomed. Only after a guide with this information is ready. as discussed (http://mail-archives.apache.org/mod_mbox/incubator- general/200712.mbox/% [EMAIL PROTECTED]), though the current policy suggests that the mentors should do most of the work this is probably unnecessary since the IPMC has already approved it. so, i'd like to see this bit of policy removed anyway. the current policy lists mandates required infrastructure tasks (mailing lists, repository). i'm not sure that this is needed at all. if it is then it would be better to simply to ask that all proposed resources are created. I do think that the new guide should make clear what tasks need to be done (not all of the tasks are listed). And what karma each task needs. There is a guide http://incubator.apache.org/guides/projects.html that could be used for the purpose. It's (strangely) linked from the left navbar under Podling Guides: Podling Mentor. It would be good if we update this guide to be as complete as the http:// incubator.apache.org/guides/graduation.html guide. WDYT? Craig the other bit is about the project status page. perhaps this does need to be explicitly stated. if so then i think it would be better to create this page as part of the 'creation' part of the process. opinions? - robert Index: site-author/incubation/Incubation_Policy.xml === --- site-author/incubation/Incubation_Policy.xml(revision 607711) +++ site-author/incubation/Incubation_Policy.xml(working copy) @@ -288,30 +288,9 @@ titleSetting Up a New Podling/title p Once a proposal has been a href='#Acceptance+By +Incubator'accepted/a -and the podling a href='#Creation+of+Podling'created/a -a a href='#Mentor'Mentor/a SHOULD initiate the creation of: +and the podling a href='#Creation+of+Podling'created/a, +the a href='#Mentor'Mentors/a SHALL a href='/guides/bootstrap.html'bootstrap/a the podling. /p -ul -lithe a href='#Ongoing+Activities'project status/a page;/li -lithe mailing lists;/li -lithe repository space;/li -/ul -p - Your project's mentors are able to undertake many of the setup - tasks. See notes about how to - a href=http://www.apache.org/dev/reporting- issues.htmlrequest project resources/a - such as new committer accounts and new mailing lists. - (Note that a committer account will not be created - a href=http://www.apache.org/dev/ pmc.html#newcommitteruntil the - Contributor License Agreement (CLA) has been recorded./a) -/p -p - Your project committers/PPMC members need to become familiar with - the a href=http://www.apache.org/dev/;ASF Infrastructure information/a - and in particular the - a href=http://www.apache.org/dev/#pmc;PMC/a notes. - Also see the a href=../guides/pmc.htmlIncubator PMC Guide/a. - /p /section section id=Ongoing+Activities titleOngoing Activities/title - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Projects in trouble or otherwise needing help
(I just rediscovered this thread as part of a year-end mail cleanup...) On Nov 14, 2007 4:32 PM, James Margaris [EMAIL PROTECTED] wrote: I am one of the pimary committers on XAP. As far as the board report, I just plain missed it until it was too late. As far as the community building is concerned, yes the lists are basically dead. However work does continue on the project, for better or worse. This is the part that both baffles me and concerns me. How is it that a group of developers can continue to work on a project without any discussion on what they're working on? The only way I could see that happening is if the project is effectively done and people are just fixing the odd bug that gets submitted, but my impression, at least, is that XAP is not a project that is close to being done. Perhaps I'm wrong about this. So where is the discussion on what happens next? The roadmap, on the web site, stops at a year ago, and XAP 0.3.0 was released early in 2007. Is there a plan to get from 0.3.0 to, say, a 1.0 release? Where can I read about that? One question that I would ask the XAP folks who work for Nexaweb (which is a majority of them, I believe): Is there any discussion at all within Nexaweb about XAP, its status, its future, and its development? Frankly, this has always seemed to me the most likely reason for the lack of discussion on the lists - the discussions are happening, but happening in person between people who work for the same company. Part of the reason I stopped using the lists is that substantive responses were rare. The only thing I ever got comments on were things like naming and copyright notices. Of course that is a chicken and egg problem to some degree, there is no community so nobody uses the lists to discuss so there is no community. It would help me if someone could help me understand how to make XAP more appealing and interesting to the Apache community. Is the problem that there are no good samples and demos? The website isn't good? Nobody understands what the point is? I like discussing technical issues with people but I don't like posting technical thoughts only to be met consistently by silence. At that point it becomes busywork, just going through the motions for the sake of appearances. Let's flip that around. If you were looking at a project with a view to getting involved in it, how likely would you be to post your thoughts and ideas if not even the people already involved are discussing anything in the open? I understand that it can be hard to bootstrap the discussion. But without a track record of discussion on the lists, there's little reason for anyone not already involved to even subscribe to those lists. People need to see that *something* is happening on the project. The threads don't all need to be deep technical discussions. For example, where's the thread on what should go into the 0.4.0 release? How should the 1.0 release be defined? Is everything - architecture, design, dev process, testing, documentation - so well nailed down for this project that the people involved don't need to talk about it? I've been involved with Struts, for example, for 7 years, and we *still* have discussions about all of those! -- Martin Cooper The XAP project is not like projects like Kabuki that never did any development and never responded on the lists. There is active development and if someone ever posted to the lists I'm sure someone would respond. Right now posting on the lists feels like playing to an empty theater. James Margaris From: Robert Burrell Donkin [mailto:[EMAIL PROTECTED] Sent: Wed 11/14/2007 2:42 PM To: general@incubator.apache.org Subject: Re: Projects in trouble or otherwise needing help (forgive the rambling reply) On Nov 12, 2007 4:47 PM, Noel J. Bergman [EMAIL PROTECTED] wrote: XAP - mailing lists show almost no discussion, mostly JIRA issues and commits XAP is an interesting case. in some ways, i think that XAP has always been short of just one independent developer showing up to scratch an itch. there was no end of endeavour in the early days from the team to try to fit in. the atmosphere has always been open, polite and encouraging to outsiders but the volumes of people turning up on list have just too far too low. i've tried to figure out some rational explanation for this but i don't have one. at apachecon EU, rob gave a very well attended session on XAP and many people had questions. but no one really showed up on list to follow up afterwards. not sure why. martin tried hard for quite a while to encourage the team to talk a lot more on the list without long term success. it's tough, though. i find it hard to explain why talking is vital for community building. most of the time, no one is listening but sometimes, just sometimes a few words flung out into the ether will connect with someone. one connection with someone who goes onto become a long
Re: Projects in trouble or otherwise needing help
On Tuesday 01 January 2008 06:20, Martin Cooper wrote: Frankly, this has always seemed to me the most likely reason for the lack of discussion on the lists - the discussions are happening, but happening in person between people who work for the same company. This is indeed a big mental barrier to overcome for companies in general. Moving from F2F discussions to open development is hard, and I must admit that even veterans like myself fall back to F2F occasionally. However, I don't think that's the case here. Sounds more like a couple of (one?) developers continue progressing their corner of the codebase. James, building community is hard, but XAP sits right on the money both in terms of technology hype/interest as well as many eyes on ASF, so I think it should be a lot easier than many other podlings. Mailing list activity is the number one gauge for external folks to make a risk assessment of will this project survive/thrive... My suggestions; 1) Start announcing development to be made. Both quite ahead of time in abstract form, as well as nitty, gritty details as you work with it. 2) Announce after-the-fact, what has been done in commits. Most people don't care reading commit logs, so sumarize rNN:MM this and that has been added/modified/deleted/changed... bla bla bla. 3) There seems to be a fair bit of JIRA issues filed in the project. Try comment on those issues on the dev mailing list. Try to create a discussion of possible solutions, in parallel to the comments on the issue. 4) There are 17 open NewFeature/Improvements in Jira right. These should serve as excellent starting points to discuss between the main developer, other developers and the reporter, what can/should be done. Personally, I don't think web site and documentation is the critical parts in this particular case to bootstrap community. There are always hard-core people who can take what you have and put it in use. That said, for mass adoption, you probably need to improve docs in various areas. You will always hear complaints on docs from users, either too much, too little, wrong level of granularity, no overview, no details, can't find X, and so on... That is normal. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
