Re: Proposals - wiki required?
On 23 November 2014 at 03:16, John D. Ament john.d.am...@gmail.com wrote: All, The current way the proposal page is written, the wiki for proposals is optional. I don't think this is the case any longer, since it looks like we request that all proposals get put there first. Does anyone mind if I rephrase the page to make it mandatory to use the wiki for proposals? +1. to be honest I thought it was mandatory. rgds jan i. John
RE: [VOTE] (new) Release Apache Metamodel incubating 4.3.0
Hi everyone, The voting period is over but we only have two IPMC votes so far (Henry Saputra and Arvind Prabhakar via the dev@metamodel mailing list). Can we proceed to release or should we somehow reactivate the vote? Best regards, Kasper From: Henry Saputra [henry.sapu...@gmail.com] Sent: 20 November 2014 16:45 To: general@incubator.apache.org Subject: Re: [VOTE] (new) Release Apache Metamodel incubating 4.3.0 +1 (binding) On Wed, Nov 19, 2014 at 2:10 PM, Kasper Sørensen kasper.soren...@humaninference.com wrote: Hi All, The previous vote on this subject was cancelled because of a misstep in the artifact signing procedure. Now we're back with a properly signed release (based on the same source code). Please vote on releasing the following candidate as Apache MetaModel version 4.3.0-incubating. The Git tag to be voted on is v4.3.0- incubating tag: https://git-wip-us.apache.org/repos/asf?p=incubator-metamodel.git;a=tag;h=refs/tags/MetaModel-4.3.0-incubating commit: https://git-wip-us.apache.org/repos/asf?p=incubator-metamodel.git;a=commit;h=eef82fb039e819b8841c55e393898260733a545b The source artifact to be voted on is: https://repository.apache.org/content/repositories/orgapachemetamodel-1004/org/apache/metamodel/MetaModel/4.3.0-incubating/MetaModel-4.3.0-incubating-source-release.zip Parent directory (including MD5, SHA1 hashes etc.) of the source is: https://repository.apache.org/content/repositories/orgapachemetamodel-1004/org/apache/metamodel/MetaModel/4.3.0-incubating Release artifacts are signed with the following key: https://people.apache.org/keys/committer/kaspersor.asc Release engineer public key id: 1FE1C2F5 Vote thread link from d...@metamodel.incubator.apache.org mailing list: http://markmail.org/thread/cksfunp5oiihbag2 Result thread link from d...@metamodel.incubator.apache.org mailing list: http://markmail.org/message/fc4adybhue6t2jay Please vote on releasing this package as Apache MetaModel 4.3.0- incubating. The vote is open for 72 hours, or until we get the needed number of votes (3 times +1). [ ] +1 Release this package as Apache MetaModel 4.3.0 -incubating [ ] -1 Do not release this package because ... More information about the MetaModel project can be found at http://metamodel.incubator.apache.org/ Thank you in advance for participating. Regards, Kasper Sørensen - 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: [VOTE] (new) Release Apache Metamodel incubating 4.3.0
On 23 November 2014 at 12:23, Kasper Sørensen kasper.soren...@humaninference.com wrote: Hi everyone, The voting period is over but we only have two IPMC votes so far (Henry Saputra and Arvind Prabhakar via the dev@metamodel mailing list). Can we proceed to release or should we somehow reactivate the vote? It has been a week of apacheCON, where many of us have been busy, and I am still catching up on mails, but let me help out. +1 (binding). So please proceed with the release. rgds jan i. Best regards, Kasper From: Henry Saputra [henry.sapu...@gmail.com] Sent: 20 November 2014 16:45 To: general@incubator.apache.org Subject: Re: [VOTE] (new) Release Apache Metamodel incubating 4.3.0 +1 (binding) On Wed, Nov 19, 2014 at 2:10 PM, Kasper Sørensen kasper.soren...@humaninference.com wrote: Hi All, The previous vote on this subject was cancelled because of a misstep in the artifact signing procedure. Now we're back with a properly signed release (based on the same source code). Please vote on releasing the following candidate as Apache MetaModel version 4.3.0-incubating. The Git tag to be voted on is v4.3.0- incubating tag: https://git-wip-us.apache.org/repos/asf?p=incubator-metamodel.git;a=tag;h=refs/tags/MetaModel-4.3.0-incubating commit: https://git-wip-us.apache.org/repos/asf?p=incubator-metamodel.git;a=commit;h=eef82fb039e819b8841c55e393898260733a545b The source artifact to be voted on is: https://repository.apache.org/content/repositories/orgapachemetamodel-1004/org/apache/metamodel/MetaModel/4.3.0-incubating/MetaModel-4.3.0-incubating-source-release.zip Parent directory (including MD5, SHA1 hashes etc.) of the source is: https://repository.apache.org/content/repositories/orgapachemetamodel-1004/org/apache/metamodel/MetaModel/4.3.0-incubating Release artifacts are signed with the following key: https://people.apache.org/keys/committer/kaspersor.asc Release engineer public key id: 1FE1C2F5 Vote thread link from d...@metamodel.incubator.apache.org mailing list: http://markmail.org/thread/cksfunp5oiihbag2 Result thread link from d...@metamodel.incubator.apache.org mailing list: http://markmail.org/message/fc4adybhue6t2jay Please vote on releasing this package as Apache MetaModel 4.3.0- incubating. The vote is open for 72 hours, or until we get the needed number of votes (3 times +1). [ ] +1 Release this package as Apache MetaModel 4.3.0 -incubating [ ] -1 Do not release this package because ... More information about the MetaModel project can be found at http://metamodel.incubator.apache.org/ Thank you in advance for participating. Regards, Kasper Sørensen - 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
[RESULT] [VOTE] Release Apache Metamodel incubating 4.3.0
Hi everyone, I'm happy to be able to tell that the VOTE for releasing Apache MetaModel 4.3.0-incubating has passed with 6 votes (3 binding). Kasper Sørensen Henry Saputra * Arvind Prabhakar * Jan I * Alberto Rodriguez Tomasz Guzialek * - indicates IPMC Thank you to everyone who participated. Best regards, Kasper
Re: Proposals - wiki required?
On Nov 22, 2014, at 6:16 PM, John D. Ament john.d.am...@gmail.com wrote: All, The current way the proposal page is written, the wiki for proposals is optional. I don't think this is the case any longer, since it looks like we request that all proposals get put there first. Other IPMC member’s strongly held opinions should not be interpreted as hard rules. Does anyone mind if I rephrase the page to make it mandatory to use the wiki for proposals? I’m sorry I was “out the past few weeks. What proposal attempted to post a proposal that was not on the wiki? What problem did that cause? IMO, it doesn’t matter so long as the original vote to accept the proposal includes the entire proposal. We should always be thinking less rules, less process, less roles. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Proposals - wiki required?
Alan, I'm referring to [1], where under Developing The Proposal and The Vote it seems to list the wiki as one solution or an option rather than the proper place to put proposals. Not any specific proposal that has come up recently. John [1]: http://incubator.apache.org/guides/proposal.html#formulating On Sun Nov 23 2014 at 9:42:28 AM Alan D. Cabrera l...@toolazydogs.com wrote: On Nov 22, 2014, at 6:16 PM, John D. Ament john.d.am...@gmail.com wrote: All, The current way the proposal page is written, the wiki for proposals is optional. I don't think this is the case any longer, since it looks like we request that all proposals get put there first. Other IPMC member’s strongly held opinions should not be interpreted as hard rules. Does anyone mind if I rephrase the page to make it mandatory to use the wiki for proposals? I’m sorry I was “out the past few weeks. What proposal attempted to post a proposal that was not on the wiki? What problem did that cause? IMO, it doesn’t matter so long as the original vote to accept the proposal includes the entire proposal. We should always be thinking less rules, less process, less roles. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Proposals - wiki required?
Yep, I think I understood which proposal page to which you refer to. My opinion is still the same. It doesn’t matter so long as the original vote to accept the proposal includes the entire proposal. We should always be thinking less rules, less process, less roles. Incubation is already a bewildering experience for podlings and the solution is not more rules and codification. We need to be fostering a culture of letting the non-critical things slide by. jmho :D Regards, Alan On Nov 23, 2014, at 6:50 AM, John D. Ament john.d.am...@gmail.com wrote: Alan, I'm referring to [1], where under Developing The Proposal and The Vote it seems to list the wiki as one solution or an option rather than the proper place to put proposals. Not any specific proposal that has come up recently. John [1]: http://incubator.apache.org/guides/proposal.html#formulating On Sun Nov 23 2014 at 9:42:28 AM Alan D. Cabrera l...@toolazydogs.com wrote: On Nov 22, 2014, at 6:16 PM, John D. Ament john.d.am...@gmail.com wrote: All, The current way the proposal page is written, the wiki for proposals is optional. I don't think this is the case any longer, since it looks like we request that all proposals get put there first. Other IPMC member’s strongly held opinions should not be interpreted as hard rules. Does anyone mind if I rephrase the page to make it mandatory to use the wiki for proposals? I’m sorry I was “out the past few weeks. What proposal attempted to post a proposal that was not on the wiki? What problem did that cause? IMO, it doesn’t matter so long as the original vote to accept the proposal includes the entire proposal. We should always be thinking less rules, less process, less roles. Regards, Alan - 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: Proposals - wiki required?
On Sun, Nov 23, 2014 at 6:40 AM, Alan D. Cabrera l...@toolazydogs.com wrote: Does anyone mind if I rephrase the page to make it mandatory to use the wiki for proposals? I’m sorry I was “out the past few weeks. What proposal attempted to post a proposal that was not on the wiki? What problem did that cause? I agree that we don't want to criminalize failure to adhere to procedural minutiae. IMO, it doesn’t matter so long as the original vote to accept the proposal includes the entire proposal. It would be inconvenient if people don't use the wiki or some other form where the evolution of the proposal can be inspected using diffs. Close reading of proposal text is costly; serious flaws can hide in small crevices. We don't want those weighing a proposal to have to perform careful review a second time for the VOTE thread. However, until there's an actual problem with people not using the wiki, we don't want to put ourselves in a position where we say you MUST use the wiki and then ignore our own rules and accept a proposal anyway. We should always be thinking less rules, less process, less roles. +1 Rules which are byzantine and opaque are hard to follow and hard to enforce. Cumbersome regulation favors the establishment, and we want to foster innovation by newcomers. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Proposals - wiki required?
On 23 November 2014 at 17:20, Marvin Humphrey mar...@rectangular.com wrote: On Sun, Nov 23, 2014 at 6:40 AM, Alan D. Cabrera l...@toolazydogs.com wrote: Does anyone mind if I rephrase the page to make it mandatory to use the wiki for proposals? I’m sorry I was “out the past few weeks. What proposal attempted to post a proposal that was not on the wiki? What problem did that cause? I agree that we don't want to criminalize failure to adhere to procedural minutiae. IMO, it doesn’t matter so long as the original vote to accept the proposal includes the entire proposal. It would be inconvenient if people don't use the wiki or some other form where the evolution of the proposal can be inspected using diffs. Close reading of proposal text is costly; serious flaws can hide in small crevices. We don't want those weighing a proposal to have to perform careful review a second time for the VOTE thread. However, until there's an actual problem with people not using the wiki, we don't want to put ourselves in a position where we say you MUST use the wiki and then ignore our own rules and accept a proposal anyway. We should always be thinking less rules, less process, less roles. +1 Rules which are byzantine and opaque are hard to follow and hard to enforce. Cumbersome regulation favors the establishment, and we want to foster innovation by newcomers. I think I am a bit lost here, or we talk in reality about 2 themes. I dont want to criminalize anybody, but on the other hand I would like to have 1 common place where to look for accepted proposals. Having the proposals, at least after acceptance, in one place should be beneficial to everyone, so how about wording it as a strong suggestion. rgds jan i. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Proposals - wiki required?
On Nov 23, 2014, at 8:40 AM, jan i j...@apache.org wrote: I dont want to criminalize anybody, but on the other hand I would like to have 1 common place where to look for accepted proposals. Having the proposals, at least after acceptance, in one place should be beneficial to everyone, so how about wording it as a strong suggestion. Let's look at how the proposal process works. It starts with a proposal email. We don't troll a particular web space looking for new proposals. Dictating that the proposals start in one place needlessly adds rules that don't solve any problems. As for storing them in one place after acceptance, why? Adding strongly worded shoulds dilutes guidelines and adds to the reading homework of new podlings that will already have the good sense to use a wiki, or something better that us old folk haven't thought of. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Proposals - wiki required?
On 23 November 2014 at 19:41, Alan Cabrera l...@toolazydogs.com wrote: On Nov 23, 2014, at 8:40 AM, jan i j...@apache.org wrote: I dont want to criminalize anybody, but on the other hand I would like to have 1 common place where to look for accepted proposals. Having the proposals, at least after acceptance, in one place should be beneficial to everyone, so how about wording it as a strong suggestion. Let's look at how the proposal process works. It starts with a proposal email. We don't troll a particular web space looking for new proposals. Dictating that the proposals start in one place needlessly adds rules that don't solve any problems. As for storing them in one place after acceptance, why? SImple so that new recruits can go and get ideas of how to interpret the different headlines. The headlines might be simple to you, but I had to look at some proposals to understand some of the headlines. I am champion for 2 projects (one seems to go in another direction) and found it very useful to point the projects at the wiki. It saved my quite a lot of explanations (and discussions). I have found that projects who want to join, dont really understand how/why a proposal is needed, giving examples of successful projects makes that part a lot easier. Adding strongly worded shoulds dilutes guidelines and adds to the reading homework of new podlings that will already have the good sense to use a wiki, or something better that us old folk haven't thought of. Like you I am against rules, and I don't care whether its wiki or foo, I simply like to know where I can find real life proposals. My idea of using should instead of rule was to signal, that it must be stored somewhere, preferable (for now) in wiki. Seen with my iPMC hat on, it is a bit of history that we should not throw away, I used it a couple of times on a couple of projects to see how they have evolved. But of course it is just my opinion, and if everybody else think differently, then I will not be the one who are difficult. rgds jan i. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Proposals - wiki required?
I'd like it to remain pink please. (look up bikeshedding on Wikipedia if this makes no sense) Trying to be more constrictive... Proposal docs are useful. The wiki is a convenient place to find them after the fact (something I find necessary at least once a month for at least one podling). Whatever the docs say about SHOULD or MUST, the fact is we put the proposal in the wiki by tradition for good reasons. Unless tradition is causing a problem there is no problem. Do we want to codify tradition? Most of our policies are flexible where they need to be (which is almost everywhere), its part of the strength of the foundation. In this case a proposal not being in the wiki would cause no irreversible harm (a minor inconvenience, yes, harm no) Is it really worth a long debate on general@? In conclusion, I don't care, as long as it remains the traditional pink, I happen to like it that way. Sent from my Windows Phone From: jan imailto:j...@apache.org Sent: 11/23/2014 11:00 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Proposals - wiki required? On 23 November 2014 at 19:41, Alan Cabrera l...@toolazydogs.com wrote: On Nov 23, 2014, at 8:40 AM, jan i j...@apache.org wrote: I dont want to criminalize anybody, but on the other hand I would like to have 1 common place where to look for accepted proposals. Having the proposals, at least after acceptance, in one place should be beneficial to everyone, so how about wording it as a strong suggestion. Let's look at how the proposal process works. It starts with a proposal email. We don't troll a particular web space looking for new proposals. Dictating that the proposals start in one place needlessly adds rules that don't solve any problems. As for storing them in one place after acceptance, why? SImple so that new recruits can go and get ideas of how to interpret the different headlines. The headlines might be simple to you, but I had to look at some proposals to understand some of the headlines. I am champion for 2 projects (one seems to go in another direction) and found it very useful to point the projects at the wiki. It saved my quite a lot of explanations (and discussions). I have found that projects who want to join, dont really understand how/why a proposal is needed, giving examples of successful projects makes that part a lot easier. Adding strongly worded shoulds dilutes guidelines and adds to the reading homework of new podlings that will already have the good sense to use a wiki, or something better that us old folk haven't thought of. Like you I am against rules, and I don't care whether its wiki or foo, I simply like to know where I can find real life proposals. My idea of using should instead of rule was to signal, that it must be stored somewhere, preferable (for now) in wiki. Seen with my iPMC hat on, it is a bit of history that we should not throw away, I used it a couple of times on a couple of projects to see how they have evolved. But of course it is just my opinion, and if everybody else think differently, then I will not be the one who are difficult. rgds jan i. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: dashboarding incubator
After awaiting for feedback about my proposal, I understand there are three different aspects that should be discussed: * Cost: As Ross pointed, the potential prize is important to evaluate a solution. Although I'd love to use the professional services of the company, the toolkit is open/free software and be freely used, which moves more attention to the next point. * Infrastructure requirements: Specially in the case we decide to provide all by ourselves, such service would have some infrastructure requirements that need to be studied, as David correctly pointed. * Technical proposition: In the end the first two aspect should not be critical if the proposition brings some value, to the project-level, Incubator or ASF. I really see strong arguments against the proposal regarding the first two aspects. The third is not that easy, since I do not see how such metrics should be used for evaluating projects, rather than just bringing some indicators. Before taking the discussion to the next level, where costs and resources need to be evaluated, I opened this discussion proposing my time and personal resources to provide a simple proof of concept. Then we should have more arguments (how much resources are actually required, how useful are the indicators the dashboard provides, etc...) to move the discussion to the next level. But of course I'd like to have the good pleasure before investing time. So I'd like to ask the following question: is there already any argument to say that inevitably the answer of the proof of concept will be negative? Cheers, On 21/11/14 21:27, Ross Gardler (MS OPEN TECH) wrote: We already evaluated the Bitergia offering - it is expensive and does not provide sufficient benefit for the money (don't get me started on how metrics are not a good evaluator of open source code...) I fully agree with the comments below. Ross -Original Message- From: jan i [mailto:j...@apache.org] Sent: Friday, November 21, 2014 12:24 PM To: general@incubator.apache.org Subject: Re: dashboarding incubator On 21 November 2014 20:44, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Fri, Nov 21, 2014 at 3:35 PM, David Nalley da...@gnsa.us wrote: ...I am generally against us standing up our own service that does this. We've had a couple of these systems over the years. (pulse.a,o for instance). It takes a non-trivial amount of work to setup and maintain such a system, and invariably it falls apart I agree, OTOH if someone wants to help third parties get the data that they need to implement such services externally that might be fine. Having our own service will only marginally provide us with something better, and will cost (in endeffect) contractor resources, so I agree with david. rgds jan i. -Bertrand - 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 -- Sergio Fernández Senior Researcher Knowledge and Media Technologies Salzburg Research Forschungsgesellschaft mbH Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria T: +43 662 2288 318 | M: +43 660 2747 925 sergio.fernan...@salzburgresearch.at http://www.salzburgresearch.at - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Proposals - wiki required?
+1 on Jan's observations, below. Also, from my experience with the Proposal for Apache OpenOffice and a few others, there is considerable refinement of proposals from first draft to the version that is essentially frozen at the time of podling-acceptance balloting. The Wiki is perfect for this, as is community involvement in the refinement. (Some podling proposals are a bit more closely-held than the way the AOO one was developed and edited, so *maybe* that doesn't matter so much.) The key thing is that early proposals are moving targets and while some are advanced by a single benevolent editor, it is useful to have a wiki for the ground-truth du jour, addition of initial committers, etc. -Original Message- From: jan i [mailto:j...@apache.org] Sent: Sunday, November 23, 2014 11:00 To: general@incubator.apache.org Subject: Re: Proposals - wiki required? On 23 November 2014 at 19:41, Alan Cabrera l...@toolazydogs.com wrote: [ ... ] As for storing them in one place after acceptance, why? SImple so that new recruits can go and get ideas of how to interpret the different headlines. The headlines might be simple to you, but I had to look at some proposals to understand some of the headlines. I am champion for 2 projects (one seems to go in another direction) and found it very useful to point the projects at the wiki. It saved my quite a lot of explanations (and discussions). I have found that projects who want to join, dont really understand how/why a proposal is needed, giving examples of successful projects makes that part a lot easier. Adding strongly worded shoulds dilutes guidelines and adds to the reading homework of new podlings that will already have the good sense to use a wiki, or something better that us old folk haven't thought of. Like you I am against rules, and I don't care whether its wiki or foo, I simply like to know where I can find real life proposals. My idea of using should instead of rule was to signal, that it must be stored somewhere, preferable (for now) in wiki. Seen with my iPMC hat on, it is a bit of history that we should not throw away, I used it a couple of times on a couple of projects to see how they have evolved. [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: dashboarding incubator
On 23 November 2014 at 20:37, Sergio Fernández sergio.fernan...@salzburgresearch.at wrote: After awaiting for feedback about my proposal, I understand there are three different aspects that should be discussed: * Cost: As Ross pointed, the potential prize is important to evaluate a solution. Although I'd love to use the professional services of the company, the toolkit is open/free software and be freely used, which moves more attention to the next point. * Infrastructure requirements: Specially in the case we decide to provide all by ourselves, such service would have some infrastructure requirements that need to be studied, as David correctly pointed. * Technical proposition: In the end the first two aspect should not be critical if the proposition brings some value, to the project-level, Incubator or ASF. I really see strong arguments against the proposal regarding the first two aspects. The third is not that easy, since I do not see how such metrics should be used for evaluating projects, rather than just bringing some indicators. Before taking the discussion to the next level, where costs and resources need to be evaluated, I opened this discussion proposing my time and personal resources to provide a simple proof of concept. Then we should have more arguments (how much resources are actually required, how useful are the indicators the dashboard provides, etc...) to move the discussion to the next level. But of course I'd like to have the good pleasure before investing time. So I'd like to ask the following question: is there already any argument to say that inevitably the answer of the proof of concept will be negative? I personally think a proof of concept would be beneficial, and might help put some of the problems raised in perspective. Infra are (with full right) concerned about new services which they potentially need to support if used by many and abandoned by the original supporter. I believe a proof of concept might end up showing this could be very simple. I dont have spare cycles to help with this, but I am available anytime for questions/test etc. rgds jan I. Cheers, On 21/11/14 21:27, Ross Gardler (MS OPEN TECH) wrote: We already evaluated the Bitergia offering - it is expensive and does not provide sufficient benefit for the money (don't get me started on how metrics are not a good evaluator of open source code...) I fully agree with the comments below. Ross -Original Message- From: jan i [mailto:j...@apache.org] Sent: Friday, November 21, 2014 12:24 PM To: general@incubator.apache.org Subject: Re: dashboarding incubator On 21 November 2014 20:44, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Fri, Nov 21, 2014 at 3:35 PM, David Nalley da...@gnsa.us wrote: ...I am generally against us standing up our own service that does this. We've had a couple of these systems over the years. (pulse.a,o for instance). It takes a non-trivial amount of work to setup and maintain such a system, and invariably it falls apart I agree, OTOH if someone wants to help third parties get the data that they need to implement such services externally that might be fine. Having our own service will only marginally provide us with something better, and will cost (in endeffect) contractor resources, so I agree with david. rgds jan i. -Bertrand - 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 -- Sergio Fernández Senior Researcher Knowledge and Media Technologies Salzburg Research Forschungsgesellschaft mbH Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria T: +43 662 2288 318 | M: +43 660 2747 925 sergio.fernan...@salzburgresearch.at http://www.salzburgresearch.at - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Proposals - wiki required?
So, my intention wasn't to start a big argument. If the feeling is that the page describes the behavior correctly let's leave it. It seemed to me like we wanted all proposals to be up on the wiki, based on the way some of the comments have come through... John On Sun Nov 23 2014 at 2:59:31 PM Dennis E. Hamilton dennis.hamil...@acm.org wrote: +1 on Jan's observations, below. Also, from my experience with the Proposal for Apache OpenOffice and a few others, there is considerable refinement of proposals from first draft to the version that is essentially frozen at the time of podling-acceptance balloting. The Wiki is perfect for this, as is community involvement in the refinement. (Some podling proposals are a bit more closely-held than the way the AOO one was developed and edited, so *maybe* that doesn't matter so much.) The key thing is that early proposals are moving targets and while some are advanced by a single benevolent editor, it is useful to have a wiki for the ground-truth du jour, addition of initial committers, etc. -Original Message- From: jan i [mailto:j...@apache.org] Sent: Sunday, November 23, 2014 11:00 To: general@incubator.apache.org Subject: Re: Proposals - wiki required? On 23 November 2014 at 19:41, Alan Cabrera l...@toolazydogs.com wrote: [ ... ] As for storing them in one place after acceptance, why? SImple so that new recruits can go and get ideas of how to interpret the different headlines. The headlines might be simple to you, but I had to look at some proposals to understand some of the headlines. I am champion for 2 projects (one seems to go in another direction) and found it very useful to point the projects at the wiki. It saved my quite a lot of explanations (and discussions). I have found that projects who want to join, dont really understand how/why a proposal is needed, giving examples of successful projects makes that part a lot easier. Adding strongly worded shoulds dilutes guidelines and adds to the reading homework of new podlings that will already have the good sense to use a wiki, or something better that us old folk haven't thought of. Like you I am against rules, and I don't care whether its wiki or foo, I simply like to know where I can find real life proposals. My idea of using should instead of rule was to signal, that it must be stored somewhere, preferable (for now) in wiki. Seen with my iPMC hat on, it is a bit of history that we should not throw away, I used it a couple of times on a couple of projects to see how they have evolved. [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: dashboarding incubator
Thanks for your roundup here (very useful). You are making it clear that this is something you might want to spend time on - I'll try and answer your final question (is there already any argument to say that inevitably the answer of the proof of concept will be negative?). The short answer is yes and no. Below I spend most of the time explaining the no, if you want the short version skip to the yes in the last para. Speaking entirely personally, I have always argued against using numbers to judge the health of a project (which is the only natural outcome from collecting such numbers). For an ASF project it's not absolute activity that is important. It's the strength and behavior of the community and its governance that is important. Metrics do not provide this information, and indeed can detract from the community health issues. For example, many years ago we had a podling that didn't graduate for a long time because we had evolved into having a hard metric on what diversity meant. It did graduate in the end and today is a thriving and productive TLP. The significant expansion of the community didn't happen until after graduation, a time when newcomers feel it is safe to invest in the project. We've since scrapped the diversity metric and reverted to the original intent of requiring a project to behave in a way that is welcoming to diverse interests (and thus capable of satisfying a diversity metric given time). My point is that while some metrics can provide indicators of something that needs looking into we need to ensure that the metrics do not become more important than community health. Personally, I do use metrics when evaluating a project, but I use ones that are readily available already through a number of other services. These are not official or sanctioned and therefore say nothing, from an ASF perspective, about the health of a project. The danger I see is that providing official metrics a) provides a level of authority to the metrics which most newcomers are ill-equipped to evaluate and b) could lead to shortcut rules like the metrics must show there is X level of diversity/activity/volume/foobar replacing proper evaluation of the project and its community. In summary, I'm not against metrics per se, I'm cautious about them becoming more important than they should be. I can imagine the tools being somewhat useful *internally* where we can ensure that expectations are properly managed. I am very cautious about using such metrics externally where they can be quoted out of context and/or misrepresented. All that being said, sponsors are increasingly asking us for metrics. For this reason I'm vary interested in cross-foundational statistics rather than statistics about specific projects. That is if you were to roll up the data from across the projects into valuable data about the foundation as a whole I can see real value with minimal risk. Sally, over on press@ is currently looking at the kind of data that would be useful to report. Ross -Original Message- From: Sergio Fernández [mailto:sergio.fernan...@salzburgresearch.at] Sent: Sunday, November 23, 2014 11:37 AM To: general@incubator.apache.org Subject: Re: dashboarding incubator After awaiting for feedback about my proposal, I understand there are three different aspects that should be discussed: * Cost: As Ross pointed, the potential prize is important to evaluate a solution. Although I'd love to use the professional services of the company, the toolkit is open/free software and be freely used, which moves more attention to the next point. * Infrastructure requirements: Specially in the case we decide to provide all by ourselves, such service would have some infrastructure requirements that need to be studied, as David correctly pointed. * Technical proposition: In the end the first two aspect should not be critical if the proposition brings some value, to the project-level, Incubator or ASF. I really see strong arguments against the proposal regarding the first two aspects. The third is not that easy, since I do not see how such metrics should be used for evaluating projects, rather than just bringing some indicators. Before taking the discussion to the next level, where costs and resources need to be evaluated, I opened this discussion proposing my time and personal resources to provide a simple proof of concept. Then we should have more arguments (how much resources are actually required, how useful are the indicators the dashboard provides, etc...) to move the discussion to the next level. But of course I'd like to have the good pleasure before investing time. So I'd like to ask the following question: is there already any argument to say that inevitably the answer of the proof of concept will be negative? Cheers, On 21/11/14 21:27, Ross Gardler (MS OPEN TECH) wrote: We already evaluated the Bitergia offering - it is expensive and does not provide sufficient
Re: dashboarding incubator
On 23/11/14 20:41, Ross Gardler (MS OPEN TECH) wrote: Metrics do not provide this information, and indeed can detract from the community health issues. In looking at http://projects.bitergia.com/apache-cloudstack/browser/, I'm wondering if any meaningful metrics can be provided. Take for example, Mailing List metrics. 1,690 thread initiators 1,467 first replies 1,973 participants; Does that mean almost 10% of the threads did not receive a response? Or, as is more likely, those are part of existing threads, but due to defective email clients, appear to be new threads? My point is that while some metrics can provide indicators of something that needs looking into we need to ensure that the metrics do not become more important than community health. +1 Going back to that Mailing List metric, is it useful to know that roughly 1.4 people participate in each thread, when those metrics give no indication of whether or not the responses help the person initiating the thread? The danger I see is that providing official metrics a) provides a level of authority to the metrics which most newcomers are ill-equipped to evaluate an b) could lead to shortcut rules like the metrics must show there is X level of diversity/activity/volume/foobar replacing proper evaluation of the project and its community. Using user support for Apache OpenOffice as an example. My sense is that the general user population uses https://forum.openoffice.org/en/forum/ rather than us...@openoffice.apache.org. I'm aware of a non-Apache project where the only reliable support is IRC. The web-forum, mailing list, and other channels don't provide any indication of that factoid, though. A metric that just looks at mailing list activity falls short for projects where most interaction occurs on either web forums, or IRC channels. Metrics are useful indicators, but only when: * What they measure is clearly indicated; * What they don't measure is clearly indicated; * What their blind points are, is clearly indicated; * They measure what they purport to measure; Even with all those criteria, metrics will be misquoted, and otherwise abused, to push a point. jonathon * English - detected * English * English javascript:void(0); signature.asc Description: OpenPGP digital signature
