[jira] [Commented] (PODLINGNAMESEARCH-8) Establish whether Apache Stanbol is a suitable name
[ https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13415975#comment-13415975 ] Fabian Christ commented on PODLINGNAMESEARCH-8: --- Trademarks search on http://www.uspto.gov/ with the Trademark Electronic Search System (TESS) Basic Word Mark Search for stanbol = No TESS records were found to match the criteria of your query. Establish whether Apache Stanbol is a suitable name - Key: PODLINGNAMESEARCH-8 URL: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-8 Project: Podling Suitable Names Search Issue Type: Suitable Name Search Reporter: Fabian Christ We have to do some investigations to ensure that Apache Stanbol is a suitable name for a TLP. People should start searching on the Web and add their findings as comments. We should state: * Evidence of the degree of open source adoption for the proposed name. * Evidence of trademark registrations for the proposed name. * Evidence of the degree of branding usage of the proposed name on the world wide web. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Apache OpenMeetings 2.0 Incubating Release Candidate 4
Dear Incubator Members, I would like to start a vote about releasing Apache OpenMeetings 2.0 Incubating RC4 RC3 was rejected because of: - Inappropriate content in NOTICE file - Incomplete build docs - missing headers in some source files - removal of JQuery Plugin Fancybox There was already a positive vote at OpenMeetings Dev mailing list. +1 PPMC yegor (mentor/IPMC), aaf (mentor), solomax, albus, german, sebawagner +1 wider community: Irina, Baskar Vote Thread: http://markmail.org/message/pmuiv4mghmavibqf Result Vote Thread: http://markmail.org/message/azenwwlcfhnxmysf Main changes are covered in the Readme: http://svn.apache.org/repos/asf/incubator/openmeetings/tags/2.0RC4/README Full Changelog: http://svn.apache.org/repos/asf/incubator/openmeetings/tags/2.0RC4/CHANGELOG Release artefacts: http://people.apache.org/~sebawagner/2.0RC4/ Tag: http://svn.apache.org/repos/asf/incubator/openmeetings/tags/2.0RC4/ PGP release keys (signed using 93A30395): http://www.apache.org/dist/incubator/openmeetings/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Best regards. -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.openmeetings.de http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
Re: Incubation state transitions and stuck projects (Was: February report review)
Here are some thoughts about this based on my particular experiences. So I won't preface each particular observation with 'In my experience.' There is a narrative around the Foundation about 'Diversity'. The narrative goes like this: once upon a time, one (or more) projects were predominantly staffed by volunteers supported by a single employer. The story goes on to describe two bad outcomes that resulted from this. In the first bad outcome, the employer's priorities changed, all the volunteers wandered away, and the project withered. In the second bad outcome, the volunteers with one employer exerted undue influence over the technical direction of the project, freezing out other contributors. I've not seen the first problem with my own eyes, but I may have seen, and swept up after, the remains of it. (Sort of like observing the nebula after the supernova has exploded.) I've seen some conflicts about the second. Not, however, in podlings, rather but in projects of long-standing. In the incubator, the stated requirement of Diversity is intended to avoid graduating projects with these problems baked in. However, before a project can even get to the doorstep of an actual diversity problem in the sense described, it has to get over another hurdle. It has to be large enough. If a podling has three people in it, the problem is not 'the same employer pays all of them to contribute' -- it is 'there are only three people'! Here, then, is the big 'community development' challenge. A small group of people with a good idea (and perhaps) some code shows up, collects mentors, and sets up shop. They learn the ropes, write more code, make releases. They make some sort of web site. And they wait, metaphorically, for the phone to ring. There are, I assert, two possible explanations for this situation. One is that, sadly, no one cares at all. No one uses the code, and so of course no one shows up to contribute. The second possibility is that there are users, but those users are not motivated to contribute. Maybe the thing works so well that no one has an itch to scratch. Maybe the users all work for organizations that don't, culturally, see the value of contributions open source. It would probably be good to try to understand which state any given small podling is in when trying to help them. Either way, this a marketing problem. The skills that write killer code don't make killer web sites, let alone exercise other marketing channels, let alone come up with ways of approaching large organizations to suggest that they might want to encourage their people to become contributors. Some podlings have very compelling technologies, and succeed without these skills. Some podlings have companies sponsoring their contributors who also put marketing money and talent to work. We're happy with this so long as they play nicely with trademarks. Some podlings, however, don't have either of these advantages, and need help. How can we help them? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubation state transitions and stuck projects (Was: February report review)
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html is an example that comdev might want to propagate? On Tue, Jul 17, 2012 at 11:07 AM, Benson Margulies bimargul...@gmail.com wrote: Here are some thoughts about this based on my particular experiences. So I won't preface each particular observation with 'In my experience.' There is a narrative around the Foundation about 'Diversity'. The narrative goes like this: once upon a time, one (or more) projects were predominantly staffed by volunteers supported by a single employer. The story goes on to describe two bad outcomes that resulted from this. In the first bad outcome, the employer's priorities changed, all the volunteers wandered away, and the project withered. In the second bad outcome, the volunteers with one employer exerted undue influence over the technical direction of the project, freezing out other contributors. I've not seen the first problem with my own eyes, but I may have seen, and swept up after, the remains of it. (Sort of like observing the nebula after the supernova has exploded.) I've seen some conflicts about the second. Not, however, in podlings, rather but in projects of long-standing. In the incubator, the stated requirement of Diversity is intended to avoid graduating projects with these problems baked in. However, before a project can even get to the doorstep of an actual diversity problem in the sense described, it has to get over another hurdle. It has to be large enough. If a podling has three people in it, the problem is not 'the same employer pays all of them to contribute' -- it is 'there are only three people'! Here, then, is the big 'community development' challenge. A small group of people with a good idea (and perhaps) some code shows up, collects mentors, and sets up shop. They learn the ropes, write more code, make releases. They make some sort of web site. And they wait, metaphorically, for the phone to ring. There are, I assert, two possible explanations for this situation. One is that, sadly, no one cares at all. No one uses the code, and so of course no one shows up to contribute. The second possibility is that there are users, but those users are not motivated to contribute. Maybe the thing works so well that no one has an itch to scratch. Maybe the users all work for organizations that don't, culturally, see the value of contributions open source. It would probably be good to try to understand which state any given small podling is in when trying to help them. Either way, this a marketing problem. The skills that write killer code don't make killer web sites, let alone exercise other marketing channels, let alone come up with ways of approaching large organizations to suggest that they might want to encourage their people to become contributors. Some podlings have very compelling technologies, and succeed without these skills. Some podlings have companies sponsoring their contributors who also put marketing money and talent to work. We're happy with this so long as they play nicely with trademarks. Some podlings, however, don't have either of these advantages, and need help. How can we help them? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubation state transitions and stuck projects (Was: February report review)
On 17 July 2012 11:44, Benson Margulies bimargul...@gmail.com wrote: http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html is an example that comdev might want to propagate? I think this is a really interesting experiment and look forward to seeing the outcomes. In many ways it simply formalises what a healthy community should be doing anyway. It might be that making this explicit in the way Maven is seeking will be beneficial. Yesterday, here at OSCON, I participated in an Outercurve Foundation session looking at this problem within their own projects. This included representatives from a wide range of open source projects and foundations. There were some interesting ideas. One, in particular, caught my eye - Ubuntu have a gamified the developer engagement process with a project called Ubuntu Accomplishments. Personally I'm conflicted by this. I don't think I like the idea of trophies as this brings competition into the community. However, the process of creating the trophies led the Ubuntu team to create task oriented documentation which looked pretty useful. In addition, their automated code for detecting and awarding accomplishments could be used to trigger a human response rather than a machine awarded trophy. For example, clearly indicating that a bug report is the contributors first bug report could prompt a quick personal email of the form thanks for taking the time... our project thrives because of people like you... we'll review soon... if you want to follow up please mail dev@ Thoughts? Ross On Tue, Jul 17, 2012 at 11:07 AM, Benson Margulies bimargul...@gmail.com wrote: Here are some thoughts about this based on my particular experiences. So I won't preface each particular observation with 'In my experience.' There is a narrative around the Foundation about 'Diversity'. The narrative goes like this: once upon a time, one (or more) projects were predominantly staffed by volunteers supported by a single employer. The story goes on to describe two bad outcomes that resulted from this. In the first bad outcome, the employer's priorities changed, all the volunteers wandered away, and the project withered. In the second bad outcome, the volunteers with one employer exerted undue influence over the technical direction of the project, freezing out other contributors. I've not seen the first problem with my own eyes, but I may have seen, and swept up after, the remains of it. (Sort of like observing the nebula after the supernova has exploded.) I've seen some conflicts about the second. Not, however, in podlings, rather but in projects of long-standing. In the incubator, the stated requirement of Diversity is intended to avoid graduating projects with these problems baked in. However, before a project can even get to the doorstep of an actual diversity problem in the sense described, it has to get over another hurdle. It has to be large enough. If a podling has three people in it, the problem is not 'the same employer pays all of them to contribute' -- it is 'there are only three people'! Here, then, is the big 'community development' challenge. A small group of people with a good idea (and perhaps) some code shows up, collects mentors, and sets up shop. They learn the ropes, write more code, make releases. They make some sort of web site. And they wait, metaphorically, for the phone to ring. There are, I assert, two possible explanations for this situation. One is that, sadly, no one cares at all. No one uses the code, and so of course no one shows up to contribute. The second possibility is that there are users, but those users are not motivated to contribute. Maybe the thing works so well that no one has an itch to scratch. Maybe the users all work for organizations that don't, culturally, see the value of contributions open source. It would probably be good to try to understand which state any given small podling is in when trying to help them. Either way, this a marketing problem. The skills that write killer code don't make killer web sites, let alone exercise other marketing channels, let alone come up with ways of approaching large organizations to suggest that they might want to encourage their people to become contributors. Some podlings have very compelling technologies, and succeed without these skills. Some podlings have companies sponsoring their contributors who also put marketing money and talent to work. We're happy with this so long as they play nicely with trademarks. Some podlings, however, don't have either of these advantages, and need help. How can we help them? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: What does 'project sponsorship' mean now?
On Jul 11, 2012, at 12:15 AM, Bertrand Delacretaz wrote: On Wed, Jul 11, 2012 at 2:24 AM, Niall Pemberton niall.pember...@gmail.com wrote: ...my 2 cents would be to make it optional - keep it where theres a synergy and interest from a real project. Where it doesn't really mean anything is when the incubator PMC is the sponsor and IMO we may as well drop that Makes sense...saying that in general podlings aren't sponsored by a PMC would better match our current reality. I noticed that the Tika board report this month states that Tiki is sponsoring the Any23 incubation. -- Rich Bowen rbo...@rcbowen.com Shosholoza
Re: What does 'project sponsorship' mean now?
On Tue, Jul 17, 2012 at 7:16 PM, Rich Bowen rbo...@rcbowen.com wrote: On Jul 11, 2012, at 12:15 AM, Bertrand Delacretaz wrote: On Wed, Jul 11, 2012 at 2:24 AM, Niall Pemberton niall.pember...@gmail.com wrote: ...my 2 cents would be to make it optional - keep it where theres a synergy and interest from a real project. Where it doesn't really mean anything is when the incubator PMC is the sponsor and IMO we may as well drop that Makes sense...saying that in general podlings aren't sponsored by a PMC would better match our current reality. I noticed that the Tika board report this month states that Tiki is sponsoring the Any23 incubation. OK, well, what do we all think this amounts to, in terms of the graduation process for Any23? -- Rich Bowen rbo...@rcbowen.com Shosholoza - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
