Re: [TRADUCCIÓN]Cadena no traducida... difícil de encontrar
El día 26 de mayo de 2012 21:13, Ariel Constenla-Haile arie...@apache.org escribió: Hola Ricardo, On Sat, May 26, 2012 at 02:50:31PM +0200, RGB ES wrote: En los foros algunos voluntarios están reportando errores de traducción. Ya están casi todos corregidos salvo el siguiente: http://user.services.openoffice.org/es/forum/viewtopic.php?p=25682#p25682 Citando al amigo Salva «Al agrupar una tabla dinámica con un campo de columnas de tipo fecha por trimestres y años se muestra Years en lugar de Años» El problema es que no sé cómo buscar esa cadena... ¿Alguna idea? Sí, bastante difícil de encontrar. Tenía entendido que el nombre de los campos es tomado del nombre de las columnas... ¿No tendrá un archivo de muestra para subir a algún lado? Saludos -- Ariel Constenla-Haile La Plata, Argentina Aquí hay un ejemplo: http://user.services.openoffice.org/es/forum/download/file.php?id=2657 Saludos Ricardo -- Para cancelar: ooo-general-es-unsubscr...@incubator.apache.org Para más información: http://www.openoffice.org/es/
Re: Flume Graduation (was Re: June reports in two weeks)
On May 26, 2012, at 9:29 PM, Arvind Prabhakar wrote: Hi Jukka, On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting jukka.zitt...@gmail.comwrote: IIUC Flume operates under an RTC model where people are not supposed to commit their own changes, which obviously makes the above data less relevant for evaluating the true diversity of the community. However, seeing only a single trivial commit by both jarcec and juhanic even though they became committers already over three months ago does seem to suggest that they may not be as comfortable in their committer role as people from Cloudera are. As you noted in your comments above - the Flume project tends to follow RTC with the reviewer committing the code. I happen to have taken up the role of the reviewer for the most part and hence you see the skewed commit counts. If you want to see the actual contribution, I would suggest looking at fixed JIRA issues by assignees. A quick report yields the following: aprabhkar - 26 - Cloudera [6] brocknoland - 19 - Cloudera [7] esammer - 56 - Cloudera [8] hshreedharan - 34 - Cloudera [9] jarcec - 6 - AVG Technologies [10] jmhsieh - 8 - Cloudera [11] juhanic - 9 - CyberAgent [12] mpercy - 34 - Cloudera [13] m...@apache.org - 1 - Trend Micro [14] prasadm - 34 - Cloudera [15] t...@cloudera.com - 3 - Cloudera [16] w...@cloudera.com - 3 - Cloudera [17] Looking at this, the average number of issues resolved by Cloudera committers (not counting Tom who is a mentor) is 26, and that for non-Cloudera committers is 5. Note that this number does not include other committer work such as the number of code reviews they have done, the number of design discussions they have participated in, something that is very valuable to the project. Another way of looking at these same statistics: Cloudera - 217 Other - 16 That means Cloudera is responsible for over 93% of the Jira issues. It is great that Cloudera is doing so much work but those stats hardly prove diversity. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Open enrollment
The open enrollment period has historically been controversial -- Crunch is not the first project to wrestle with it. Just to re-iterate, the issue with Crunch was not whether or not that group decided to have an open enrollment or not. The issue was that the announced policy to not have one was selectively ignored for one volunteer versus another. After announcing its intention to go with a closed enrollment, an exception was made: the consensus was that your background is uniquely valuable to the project, and that we would like to have you with us as an initial committer. which is a fancy way of saying 'we're going to make an exception to our own policy just for your case' - a pretty bad foot for a merit-based effort to get off on. Open enrollment, closed enrollment or the hybrid you're suggesting all can (or not) work fine because they're all fair rules for the new group to build on. -jakob - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Open enrollment
Sent from my mobile device, please forgive errors and brevity. On May 27, 2012 5:44 AM, Marvin Humphrey mar...@rectangular.com wrote: On Sat, May 26, 2012 at 3:02 PM, Benson Margulies bimargul...@gmail.com wrote: I'll see Jukka one and raise him one. I have advised potential podlings to be very conservative with their initial list, and keep some potential contributors in their collective back pocket. This gives them a ready-made source of community growth, which is typically the scarcest and most precious commodity to a podling. +1 I'm less seasoned than others here who have done a lot of Mentoring, but my impression is that the act of identifying, nominating and voting in a new committer or PPMC member is a valuable experience for a fledgling community in and of itself -- going through the process seems to be beneficial, not just in terms of securing a new recruit and boosting their morale, but for those doing the recruiting as they debate and become comfortable with granting privileges to new contributors. on almost all of the podlings I've worked with a mentor has prompted the first nomination. In most a discussion of is it too early results. Keeping known people out of the initial contributor list In order to keep some potential contributors in their collective back pocket seems wrong to me. Either someone has merit at proposal stage (put them in) or they don't (show the community how to build and recognise merit). I don't like even mentors being given commit status without merit (remember merit is not transferable). I'm not sure where this open enrollment thing came from, but I've never liked like it. It made sense on AOO since there was a need to be open to a previous fork. This is not the case in most other projects. I believe there may be a best-of-both-worlds solution: * Incubation proposals should have separate sections for Initial Committers and Initial PPMC Members. Too much hierarchy, the ASF is flat. This is hard to understand if we introduce layers to incubation. * There should be text in the proposal encouraging people to add themselves to the list of Initial Committers and to introduce themselves on general@incubator -- but no such text regarding the list of Initial PPMC members. Why can't they just be contributors needing to earn merit just as they would in a TLP? If a new project wants to have open enrollment for some reason then the champion should advise them on a case by case basis. Ross Ross
Re: Flume Graduation (was Re: June reports in two weeks)
There is no diversity requirement for graduating from the incubator. In many ways, incubation hinders community growth. The requirement is that the project makes decisions as an Apache project, not in private, which is harder to get used to doing if a lot of people share the same office. Diversity is only a warning sign that means we need to check for decisions made in our forums and advise accordingly. It is not an end in itself, nor has lack of diversity hindered other projects from continuing on to build a larger community as a TLP. Roy On May 26, 2012, at 11:44 PM, Ralph Goers ralph.go...@dslextreme.com wrote: On May 26, 2012, at 9:29 PM, Arvind Prabhakar wrote: Hi Jukka, On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting jukka.zitt...@gmail.comwrote: IIUC Flume operates under an RTC model where people are not supposed to commit their own changes, which obviously makes the above data less relevant for evaluating the true diversity of the community. However, seeing only a single trivial commit by both jarcec and juhanic even though they became committers already over three months ago does seem to suggest that they may not be as comfortable in their committer role as people from Cloudera are. As you noted in your comments above - the Flume project tends to follow RTC with the reviewer committing the code. I happen to have taken up the role of the reviewer for the most part and hence you see the skewed commit counts. If you want to see the actual contribution, I would suggest looking at fixed JIRA issues by assignees. A quick report yields the following: aprabhkar - 26 - Cloudera [6] brocknoland - 19 - Cloudera [7] esammer - 56 - Cloudera [8] hshreedharan - 34 - Cloudera [9] jarcec - 6 - AVG Technologies [10] jmhsieh - 8 - Cloudera [11] juhanic - 9 - CyberAgent [12] mpercy - 34 - Cloudera [13] m...@apache.org - 1 - Trend Micro [14] prasadm - 34 - Cloudera [15] t...@cloudera.com - 3 - Cloudera [16] w...@cloudera.com - 3 - Cloudera [17] Looking at this, the average number of issues resolved by Cloudera committers (not counting Tom who is a mentor) is 26, and that for non-Cloudera committers is 5. Note that this number does not include other committer work such as the number of code reviews they have done, the number of design discussions they have participated in, something that is very valuable to the project. Another way of looking at these same statistics: Cloudera - 217 Other - 16 That means Cloudera is responsible for over 93% of the Jira issues. It is great that Cloudera is doing so much work but those stats hardly prove diversity. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Flume Graduation (was Re: June reports in two weeks)
Roy, What you are saying directly contradicts http://incubator.apache.org/guides/graduation.html#community, especially the statement Basically this means that when a project mostly consists of contributors from one company, this is a sign of not being diverse enough. Now, if that page is wrong and diversity is not a requirement for graduation then, of course, that would certainly remove any objections I have for Flume's graduation. However, I've heard it said that the ASF does not want to simply provide the infrastructure for companies to host their products on. Ralph On May 27, 2012, at 1:35 AM, Roy T. Fielding wrote: There is no diversity requirement for graduating from the incubator. In many ways, incubation hinders community growth. The requirement is that the project makes decisions as an Apache project, not in private, which is harder to get used to doing if a lot of people share the same office. Diversity is only a warning sign that means we need to check for decisions made in our forums and advise accordingly. It is not an end in itself, nor has lack of diversity hindered other projects from continuing on to build a larger community as a TLP. Roy On May 26, 2012, at 11:44 PM, Ralph Goers ralph.go...@dslextreme.com wrote: On May 26, 2012, at 9:29 PM, Arvind Prabhakar wrote: Hi Jukka, On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting jukka.zitt...@gmail.comwrote: IIUC Flume operates under an RTC model where people are not supposed to commit their own changes, which obviously makes the above data less relevant for evaluating the true diversity of the community. However, seeing only a single trivial commit by both jarcec and juhanic even though they became committers already over three months ago does seem to suggest that they may not be as comfortable in their committer role as people from Cloudera are. As you noted in your comments above - the Flume project tends to follow RTC with the reviewer committing the code. I happen to have taken up the role of the reviewer for the most part and hence you see the skewed commit counts. If you want to see the actual contribution, I would suggest looking at fixed JIRA issues by assignees. A quick report yields the following: aprabhkar - 26 - Cloudera [6] brocknoland - 19 - Cloudera [7] esammer - 56 - Cloudera [8] hshreedharan - 34 - Cloudera [9] jarcec - 6 - AVG Technologies [10] jmhsieh - 8 - Cloudera [11] juhanic - 9 - CyberAgent [12] mpercy - 34 - Cloudera [13] m...@apache.org - 1 - Trend Micro [14] prasadm - 34 - Cloudera [15] t...@cloudera.com - 3 - Cloudera [16] w...@cloudera.com - 3 - Cloudera [17] Looking at this, the average number of issues resolved by Cloudera committers (not counting Tom who is a mentor) is 26, and that for non-Cloudera committers is 5. Note that this number does not include other committer work such as the number of code reviews they have done, the number of design discussions they have participated in, something that is very valuable to the project. Another way of looking at these same statistics: Cloudera - 217 Other - 16 That means Cloudera is responsible for over 93% of the Jira issues. It is great that Cloudera is doing so much work but those stats hardly prove diversity. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Flume Graduation (was Re: June reports in two weeks)
Hi, On Sun, May 27, 2012 at 6:29 AM, Arvind Prabhakar arv...@apache.org wrote: As you noted in your comments above - the Flume project tends to follow RTC with the reviewer committing the code. I happen to have taken up the role of the reviewer for the most part and hence you see the skewed commit counts. It might be useful if you for example expanded the How to Commit wiki page [1] with a better description of what a reviewer should take in to account when committing reviewed changes. Things that might be obvious to you and others who've been around for longer, but not necessarily for newcomers. The more people you have committing code, the less the project is dependent on the silent knowledge of any single contributor. On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting jukka.zitt...@gmail.comwrote: Do you think this is a problem for the community? If yes, how do you plan to fix it? If not, why? I don't think this is a problem because while most Cloudera committers have the luxury of working on the project during regular working hours, others do that during their off hours. Hence the majority of contributions coming from Cloudera. OK, fair enough. Such a scenario exists or has existed also in other Apache projects like Jackrabbit that I'm most familiar with. It can be a tricky balance to maintain a level playing field in such cases, for example by making sure that all relevant project discussions happen out in the open and that some committers don't feel like junior partners with less ability to influence the project. It sounds like you have a reasonably good handle on that, so I'm not too worried, but my instinct suggests that the strict RTC model and distinction between committers and (P)PMC members may be structural factors that could easily end up tripping that balance. Are these really essential tools for the project or could you live without them? Other solutions to the RTC model include separate maintenance branches with stricter review and testing requirements, and the only cases where I really see a need for the committer/(P)PMC separation is with umbrella projects or special cases like GSoC students or co-operation across project boundaries. I know you have good arguments for the way things work in Flume now, and ultimately you're the ones to decide how you want to work. So take the above just as friendly suggestions for things you may want to consider. Whatever the outcome, it would be good for Flume to document such decisions and the rationale behind them as a set of project bylaws. This is what the bylaws section of the graduation resolution is about: RESOLVED, that the initial Apache $project PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache $foo Project; and be it further [1] https://cwiki.apache.org/confluence/display/FLUME/How+to+Commit BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Flume Graduation (was Re: June reports in two weeks)
Thanks Jukka for your suggestions. 1. Regarding wiki - I have taken a note of that and will update it soon. 2. Regarding doing away with the difference between PPMC and committers, I am told that other projects do this during graduation. I.e., they promote all existing committers to PMC status during graduation. If we do that, the diversity concern will be addressed and we can then debate the bylaws once the PMC is formed. Thanks, Arvind Prabhakar On Sun, May 27, 2012 at 2:40 AM, Jukka Zitting jukka.zitt...@gmail.comwrote: Hi, On Sun, May 27, 2012 at 6:29 AM, Arvind Prabhakar arv...@apache.org wrote: As you noted in your comments above - the Flume project tends to follow RTC with the reviewer committing the code. I happen to have taken up the role of the reviewer for the most part and hence you see the skewed commit counts. It might be useful if you for example expanded the How to Commit wiki page [1] with a better description of what a reviewer should take in to account when committing reviewed changes. Things that might be obvious to you and others who've been around for longer, but not necessarily for newcomers. The more people you have committing code, the less the project is dependent on the silent knowledge of any single contributor. On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Do you think this is a problem for the community? If yes, how do you plan to fix it? If not, why? I don't think this is a problem because while most Cloudera committers have the luxury of working on the project during regular working hours, others do that during their off hours. Hence the majority of contributions coming from Cloudera. OK, fair enough. Such a scenario exists or has existed also in other Apache projects like Jackrabbit that I'm most familiar with. It can be a tricky balance to maintain a level playing field in such cases, for example by making sure that all relevant project discussions happen out in the open and that some committers don't feel like junior partners with less ability to influence the project. It sounds like you have a reasonably good handle on that, so I'm not too worried, but my instinct suggests that the strict RTC model and distinction between committers and (P)PMC members may be structural factors that could easily end up tripping that balance. Are these really essential tools for the project or could you live without them? Other solutions to the RTC model include separate maintenance branches with stricter review and testing requirements, and the only cases where I really see a need for the committer/(P)PMC separation is with umbrella projects or special cases like GSoC students or co-operation across project boundaries. I know you have good arguments for the way things work in Flume now, and ultimately you're the ones to decide how you want to work. So take the above just as friendly suggestions for things you may want to consider. Whatever the outcome, it would be good for Flume to document such decisions and the rationale behind them as a set of project bylaws. This is what the bylaws section of the graduation resolution is about: RESOLVED, that the initial Apache $project PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache $foo Project; and be it further [1] https://cwiki.apache.org/confluence/display/FLUME/How+to+Commit BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Prototype ASF Mailing List Request form
Nick Kew wrote on Sat, May 26, 2012 at 07:39:48 +0100: On 26 May 2012, at 03:54, Sam Ruby wrote: https://whimsy.apache.org/infra/mlreq Nothing fancy: simple data gathering. Output will be validated and placed into svn as input to another tool down the chain. The topic I would like to discuss is what additional input validation should be done. Mailing list names have specific formats. Within the incubator, podling mailing list names are expected to have a specific format. But the mapping of podling names to mailing list names sometimes varies... Suggestions welcome. I'm starting with the incubator as it is the source for a bulk of the requests... [foo] @ [bar] .apache.org ? The form is ASF wide. You guys will enter incubator for [bar]. What about a toggle for a private list? Or is that determined on name alone? Easy to add if there's a use case. apmail hat on, I would still like sanity checking to avoid the case where someone requests a foo-private list and forgets to tick the Make it private? checkbox. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Prototype ASF Mailing List Request form
sebb wrote on Sat, May 26, 2012 at 12:09:48 +0100: On 26 May 2012 03:54, Sam Ruby ru...@intertwingly.net wrote: https://whimsy.apache.org/infra/mlreq Nothing fancy: simple data gathering. Output will be validated and placed into svn as input to another tool down the chain. The topic I would like to discuss is what additional input validation should be done. Mailing list names have specific formats. Within the incubator, podling mailing list names are expected to have a specific format. But the mapping of podling names to mailing list names sometimes varies... Suggestions welcome. I'm starting with the incubator as it is the source for a bulk of the requests... Might be useful to provide examples on the form for some of the fields. Not sure what the Replies check-box is about. I assume it might be for lists like commits@ where the PMC wants replies to go to dev@ If selected, should it not provide a new box for the Reply-To address? Semantics: the form only provides UI for enabling or disabling reply-to headers that point to the list itself. Reply-to: dev@ on commits@ list happens by default and is not controlled by the form. Sam --- this Reply-To on commits@ lists is one place where the -s argument to makelist-apache.sh might matter --- I assume -s goober commits will result in Reply-To: goober-dev@ in headeradd. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Prototype ASF Mailing List Request form
Daniel Shahaf wrote on Sun, May 27, 2012 at 14:12:54 +0300: Nick Kew wrote on Sat, May 26, 2012 at 07:39:48 +0100: On 26 May 2012, at 03:54, Sam Ruby wrote: https://whimsy.apache.org/infra/mlreq Nothing fancy: simple data gathering. Output will be validated and placed into svn as input to another tool down the chain. The topic I would like to discuss is what additional input validation should be done. Mailing list names have specific formats. Within the incubator, podling mailing list names are expected to have a specific format. But the mapping of podling names to mailing list names sometimes varies... Suggestions welcome. I'm starting with the incubator as it is the source for a bulk of the requests... [foo] @ [bar] .apache.org ? The form is ASF wide. You guys will enter incubator for [bar]. What about a toggle for a private list? Or is that determined on name alone? Easy to add if there's a use case. apmail hat on, I would still like sanity checking to avoid the case where someone requests a foo-private list and forgets to tick the Make it private? checkbox. There _is_ a use case: some f...@apache.org lists will need such an option. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Open enrollment
On Sun, May 27, 2012 at 12:57 AM, Ross Gardler rgard...@opendirective.com wrote: * Incubation proposals should have separate sections for Initial Committers and Initial PPMC Members. Too much hierarchy, the ASF is flat. This is hard to understand if we introduce layers to incubation. Well, now *I'm* confused. :) The distinction between committer and PMC member exists at the ASF. Some podlings choose to unify the roles of committer and PPMC member, others do not -- same as with TLPs, some of which unify the roles of committer and PMC Member while others do not. My guess is that you believe the two roles ought to be unified, a position which Chris Mattmann argued passionately for and at great length during Lucy's incubation. I remain unpersuaded, but as I don't want to step in that acrimonious debate, let's sidestep... Why can't they just be contributors needing to earn merit just as they would in a TLP? OK, then how about a place for people to sign up for the podling dev list in advance? In my opinion, there should continue to be a way for new people to get involved during the proposal phase. The reason is simple: the less time your signup sheet is out there, the fewer names you'll collect. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Open enrollment
On May 27, 2012 1:55 PM, Marvin Humphrey mar...@rectangular.com wrote: On Sun, May 27, 2012 at 12:57 AM, Ross Gardler rgard...@opendirective.com wrote: * Incubation proposals should have separate sections for Initial Committers and Initial PPMC Members. Too much hierarchy, the ASF is flat. This is hard to understand if we introduce layers to incubation. Well, now *I'm* confused. :) The distinction between committer and PMC member exists at the ASF. Some podlings choose to unify the roles of committer and PPMC member, others do not -- same as with TLPs, some of which unify the roles of committer and PMC Member while others do not. Yes, and in the incubator the separation is the IPMC. My guess is that you believe the two roles ought to be unified Depends on the project, entry into the incubator is not, IMHO, the time to consider such a complex issue. Why can't they just be contributors needing to earn merit just as they would in a TLP? OK, then how about a place for people to sign up for the podling dev list in advance? Sure, but to what end? If the are interested enough they will sign up whether they signed the wiki page or not. Having said that there is no harm and if projects and champions see benefit then fair enough. Ross In my opinion, there should continue to be a way for new people to get involved during the proposal phase. The reason is simple: the less time your signup sheet is out there, the fewer names you'll collect. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Prototype ASF Mailing List Request form
Nice work Sam ;) May I suggest adding some fields to ease data entry even more: 1- A checkbox indicating whether or not the mailing list is for an incubator project or not 2- Another list of checkboxes which are enabled only when the incubator checkbox is enabled: 2.1- Dvelopment 2.2- Commits 2.3- Private 2.4- Users(*) For the first three ones they can be checked by default as they are required by all Incubator projects, the last one for users can be checked sometimes when a new podling is in need for a users list This will ease data entry a lot for new podlings instead of making a new request for each mailing list a mentor can just in one request send all data required by the tool On Sun, May 27, 2012 at 1:41 PM, Daniel Shahaf d...@daniel.shahaf.namewrote: Daniel Shahaf wrote on Sun, May 27, 2012 at 14:12:54 +0300: Nick Kew wrote on Sat, May 26, 2012 at 07:39:48 +0100: On 26 May 2012, at 03:54, Sam Ruby wrote: https://whimsy.apache.org/infra/mlreq Nothing fancy: simple data gathering. Output will be validated and placed into svn as input to another tool down the chain. The topic I would like to discuss is what additional input validation should be done. Mailing list names have specific formats. Within the incubator, podling mailing list names are expected to have a specific format. But the mapping of podling names to mailing list names sometimes varies... Suggestions welcome. I'm starting with the incubator as it is the source for a bulk of the requests... [foo] @ [bar] .apache.org ? The form is ASF wide. You guys will enter incubator for [bar]. What about a toggle for a private list? Or is that determined on name alone? Easy to add if there's a use case. apmail hat on, I would still like sanity checking to avoid the case where someone requests a foo-private list and forgets to tick the Make it private? checkbox. There _is_ a use case: some f...@apache.org lists will need such an option. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: Open enrollment
On Sun, May 27, 2012 at 12:08 AM, Jakob Homan jgho...@gmail.com wrote: The open enrollment period has historically been controversial -- Crunch is not the first project to wrestle with it. Just to re-iterate, the issue with Crunch was not whether or not that group decided to have an open enrollment or not. The issue was that the announced policy to not have one was selectively ignored for one volunteer versus another. After announcing its intention to go with a closed enrollment, an exception was made: the consensus was that your background is uniquely valuable to the project, and that we would like to have you with us as an initial committer. which is a fancy way of saying 'we're going to make an exception to our own policy just for your case' - a pretty bad foot for a merit-based effort to get off on. The text of the entire email that Jakob is quoting from: Thank you Vinod. I wasn't sure of the right protocol for this sort of thing, as my expectation was that the initial committers would be drawn from the people who had contributed to Crunch already. This thread from when S4 entered the incubator was particularly illuminating: http://markmail.org/message/aw54w4mhg4zfegpn After talking it over with my co-submitters, the consensus was that your background is uniquely valuable to the project, and that we would like to have you with us as an initial committer. There was not an email before that one that announced a policy (or even an opinion) with respect to open or closed enrollment, and the reference to the S4 thread only indicated that it was illuminating, not that it was policy. I think that not making an explicit policy announcement was a mistake on our part, because the interpretation was ambiguous and that led directly to an ugly start for the project. At a minimum, I think it would be wise for the incubator documentation to tell new projects to announce a policy as part of their proposal, so that others do not make the same mistake. That announcement could be anything from The initial committers will be made up exclusively from existing contributors to We would like to consider potential additional committers on a case-by-case basis to Anyone from the Apache community is welcome to join as an initial committer. Then there could be explicit discussion on the thread about the pros and cons of the project's choice before the proposal went to a vote. Open enrollment, closed enrollment or the hybrid you're suggesting all can (or not) work fine because they're all fair rules for the new group to build on. -jakob - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Director of Data Science Cloudera Twitter: @josh_wills - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Open enrollment
Ross, I can see why my 'sandbag' approach makes you uncomfortable. I've suggested it once or twice when a proposed podling had a lot of interested parties already involved. This is a two-edged situation. On the one hand, instant size and diversity. On the other hand, that may represent the pool of participants for some time to come, leaving the podling a bit stalled when they have done everything to deserve graduation except add people. Overdone, this amounts to cheating. George is thinking about contributing. Great, let's have him walk the process and get added, instead of adding him to the initial list. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Prototype ASF Mailing List Request form
On May 27, 2012, at 4:12 AM, Daniel Shahaf wrote: Nick Kew wrote on Sat, May 26, 2012 at 07:39:48 +0100: On 26 May 2012, at 03:54, Sam Ruby wrote: https://whimsy.apache.org/infra/mlreq Nothing fancy: simple data gathering. Output will be validated and placed into svn as input to another tool down the chain. The topic I would like to discuss is what additional input validation should be done. Mailing list names have specific formats. Within the incubator, podling mailing list names are expected to have a specific format. But the mapping of podling names to mailing list names sometimes varies... Suggestions welcome. I'm starting with the incubator as it is the source for a bulk of the requests... [foo] @ [bar] .apache.org ? The form is ASF wide. You guys will enter incubator for [bar]. Most incubator lists are of the form foo-dev @ incubator .apache.org. It might be good to have a drop down with the common dev, user, private aliases already listed, and perhaps an option [] - [] @ incubator.apache.org Craig What about a toggle for a private list? Or is that determined on name alone? Easy to add if there's a use case. apmail hat on, I would still like sanity checking to avoid the case where someone requests a foo- private list and forgets to tick the Make it private? checkbox. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
