Re: Apache Metrics, Not Apache Humans
On 11/18/2015 06:28 PM, Louis Suárez-Potts wrote: > PS Alas, "scores" are chalked against the manager of communities who > fails to satisfy the beany needs of misguided marketing. (Beany > needs=bean counter needs.) We should have a support group. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache Metrics, Not Apache Humans
On 17 November 2015 at 16:20, Ross Gardler wrote: > Summary of my objection: community building is an art not a science, there is > no "score" that can be placed upon a community. True. Louis. PS Alas, "scores" are chalked against the manager of communities who fails to satisfy the beany needs of misguided marketing. (Beany needs=bean counter needs.) -- Louis Suárez-Potts Mobile: +1.416.625.3843 (ET) Skype: louisiam Twitter: @luispo G+: https://plus.google.com/+LouisSuárezPotts - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache Metrics, Not Apache Humans
On 11/17/2015 08:13 PM, Marko Rodriguez wrote: > Hi, > > I suppose the distilled intention of the proposal is to identify the > answer(s) to the following question: > > What makes a "good" open source project? > > As I read on general@ and from our project's mentors, "good" is grounded in > personal experience (i.e. anecdotes). Why not use the data you gather to > quantify "good." This way its not a "well I believe," its more of "in this > particular situation given these variables, there is a X% success rate." > Also, it leads to more exploration -- "Huh, I don't think I've ever seen an > Apache project do it like that -- hell, give it a try and lets glean the > stats from it. If anything, we learn." > > Personally, I'm all about: "Do whatever you want." (try it -- who cares as > long as its legal). However, if there must be structure, perhaps The Apache > Way is a local optima? Only a broad statistical landscape will tell. And only > in data gathering and analysis will that landscape be constructed from the > numerous, diverse social/technical experiments -- i.e. Apache projects! > Without the openness and computational introspection, Apache podlings will > simply internalize the objective of "just do as expected and graduate." The > problem is that this only engrains a particular philosophy/approach that may > not be fit in the long run. It just seems (to me) that this > "carrot-on-a-stick model" of podling/top-level is outdated much like our > modern education system (just take the classes, get the grades, give the > teacher an apple, and get the hell out of here). > > Again -- just shootin' ideas. I have no bee-in-the-bonet or axe-to-grind. > I've just become interested in how your minds tick... > So, I am a huge fan of collecting metrics, trying to squeeze wisdom out of them, and making community decisions based on what's likely to succeed. The trouble is, past performance is not a guarantee - or even a reliable indicator - of future performance, because there are so many variables to consider. So, yes, we should do this, but we should avoid trusting it completely, because it is known to fail. We can cite numerous examples of deeply dysfunctional, hostile, unhealthy communities that are HUGELY successful. Several come to mind immediately. We can also cite friendly, welcoming, well-managed communities that are unable to achieve any measurable success in terms of actual user adoption. In each of these case, the metrics are useful, and interesting, and worthy of study, and even suggest decisions that should/could be made. But they are misleading unless a human is there to interpret and implement them. I'd love to see more things like Black Duck and Bitergia, and see them being open sourced like some of the work that Roberto Galoppini has worked on, and see more intelligence and less shot-in-the-dark understanding coming out of them. If there is wisdom to be gained, and things that can be consistently reproducible, we should pursue that. So much in open source, however, depends on personalities, and we tend to attract some of the more ... ahem ... interesting personalities in the world. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Apache Metrics, Not Apache Humans
It's a problem when "mentors" tell projects what to do. The role of a mentor is to explain the pros and cons of different approaches so that the community can make an optimal decision The Apache Way is indeed about doing what is right for the community. Its not a prescriptive model. There are very few things in the Apache Way that are fixed (meritocracy, up due diligence etc.) everything else is flexible so it can be optimized for specific community profiles. It's true that this can be confusing, but understanding the options and the related pros and cons is what leads to the right decision for that community. Ross Sent from my Windows Phone From: Marko Rodriguez<mailto:okramma...@gmail.com> Sent: 11/17/2015 5:14 PM To: general@incubator.apache.org<mailto:general@incubator.apache.org> Subject: Re: Apache Metrics, Not Apache Humans Hi, I suppose the distilled intention of the proposal is to identify the answer(s) to the following question: What makes a "good" open source project? As I read on general@ and from our project's mentors, "good" is grounded in personal experience (i.e. anecdotes). Why not use the data you gather to quantify "good." This way its not a "well I believe," its more of "in this particular situation given these variables, there is a X% success rate." Also, it leads to more exploration -- "Huh, I don't think I've ever seen an Apache project do it like that -- hell, give it a try and lets glean the stats from it. If anything, we learn." Personally, I'm all about: "Do whatever you want." (try it -- who cares as long as its legal). However, if there must be structure, perhaps The Apache Way is a local optima? Only a broad statistical landscape will tell. And only in data gathering and analysis will that landscape be constructed from the numerous, diverse social/technical experiments -- i.e. Apache projects! Without the openness and computational introspection, Apache podlings will simply internalize the objective of "just do as expected and graduate." The problem is that this only engrains a particular philosophy/approach that may not be fit in the long run. It just seems (to me) that this "carrot-on-a-stick model" of podling/top-level is outdated much like our modern education system (just take the classes, get the grades, give the teacher an apple, and get the hell out of here). Again -- just shootin' ideas. I have no bee-in-the-bonet or axe-to-grind. I've just become interested in how your minds tick... Take care, Marko. https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmarkorodriguez.com&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cb67cecadf1a1471c1f6008d2efb58e68%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wor4U8Yvu1ZkTLU4b5BwrCyQy6SfMxdQ018eOQJCy%2bM%3d On Nov 17, 2015, at 3:12 PM, Pierre Smits wrote: > It is not the metrics that vote. Humans do. > > Best regards, > > Pierre Smits > > *OFBiz Extensions Marketplace* > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2foem.ofbizci.net%2foci-2%2f&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cb67cecadf1a1471c1f6008d2efb58e68%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=H4rR211mWURZkS1B1iBFsUOr58Gn1sid5symV9DLGAE%3d > > On Tue, Nov 17, 2015 at 10:39 PM, Marvin Humphrey > wrote: > >> On Sun, Nov 15, 2015 at 10:49 PM, Bertrand Delacretaz >> wrote: >>> On Sun, Nov 15, 2015 at 7:20 PM, Marko Rodriguez >> wrote: >>>> ...The Apache Way should be about metrics.. >>>> ...Get the human out of the loop! >>> >>> No. >>> >>> The ASF is built on the collective wisdom of its members and >>> community. Having metrics-based projects might be an interesting >>> experiment, but that's not the ASF. >> >> My read of the proposal is that reduces uncertainty for a project >> attempting to achieve "good health" and discredits any critiques which >> might be raised by individual humans. Gaming the system can be seen as >> justifiable if you don't consider the critiques valid and chafe under >> an authority whose legitimacy you question. >> >> Marvin Humphrey >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >>
Re: Apache Metrics, Not Apache Humans
Hi, I suppose the distilled intention of the proposal is to identify the answer(s) to the following question: What makes a "good" open source project? As I read on general@ and from our project's mentors, "good" is grounded in personal experience (i.e. anecdotes). Why not use the data you gather to quantify "good." This way its not a "well I believe," its more of "in this particular situation given these variables, there is a X% success rate." Also, it leads to more exploration -- "Huh, I don't think I've ever seen an Apache project do it like that -- hell, give it a try and lets glean the stats from it. If anything, we learn." Personally, I'm all about: "Do whatever you want." (try it -- who cares as long as its legal). However, if there must be structure, perhaps The Apache Way is a local optima? Only a broad statistical landscape will tell. And only in data gathering and analysis will that landscape be constructed from the numerous, diverse social/technical experiments -- i.e. Apache projects! Without the openness and computational introspection, Apache podlings will simply internalize the objective of "just do as expected and graduate." The problem is that this only engrains a particular philosophy/approach that may not be fit in the long run. It just seems (to me) that this "carrot-on-a-stick model" of podling/top-level is outdated much like our modern education system (just take the classes, get the grades, give the teacher an apple, and get the hell out of here). Again -- just shootin' ideas. I have no bee-in-the-bonet or axe-to-grind. I've just become interested in how your minds tick... Take care, Marko. http://markorodriguez.com On Nov 17, 2015, at 3:12 PM, Pierre Smits wrote: > It is not the metrics that vote. Humans do. > > Best regards, > > Pierre Smits > > *OFBiz Extensions Marketplace* > http://oem.ofbizci.net/oci-2/ > > On Tue, Nov 17, 2015 at 10:39 PM, Marvin Humphrey > wrote: > >> On Sun, Nov 15, 2015 at 10:49 PM, Bertrand Delacretaz >> wrote: >>> On Sun, Nov 15, 2015 at 7:20 PM, Marko Rodriguez >> wrote: ...The Apache Way should be about metrics.. ...Get the human out of the loop! >>> >>> No. >>> >>> The ASF is built on the collective wisdom of its members and >>> community. Having metrics-based projects might be an interesting >>> experiment, but that's not the ASF. >> >> My read of the proposal is that reduces uncertainty for a project >> attempting to achieve "good health" and discredits any critiques which >> might be raised by individual humans. Gaming the system can be seen as >> justifiable if you don't consider the critiques valid and chafe under >> an authority whose legitimacy you question. >> >> Marvin Humphrey >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >>
Re: Apache Metrics, Not Apache Humans
It is not the metrics that vote. Humans do. Best regards, Pierre Smits *OFBiz Extensions Marketplace* http://oem.ofbizci.net/oci-2/ On Tue, Nov 17, 2015 at 10:39 PM, Marvin Humphrey wrote: > On Sun, Nov 15, 2015 at 10:49 PM, Bertrand Delacretaz > wrote: > > On Sun, Nov 15, 2015 at 7:20 PM, Marko Rodriguez > wrote: > >> ...The Apache Way should be about metrics.. > >>...Get the human out of the loop! > > > > No. > > > > The ASF is built on the collective wisdom of its members and > > community. Having metrics-based projects might be an interesting > > experiment, but that's not the ASF. > > My read of the proposal is that reduces uncertainty for a project > attempting to achieve "good health" and discredits any critiques which > might be raised by individual humans. Gaming the system can be seen as > justifiable if you don't consider the critiques valid and chafe under > an authority whose legitimacy you question. > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Apache Metrics, Not Apache Humans
On Sun, Nov 15, 2015 at 10:49 PM, Bertrand Delacretaz wrote: > On Sun, Nov 15, 2015 at 7:20 PM, Marko Rodriguez wrote: >> ...The Apache Way should be about metrics.. >>...Get the human out of the loop! > > No. > > The ASF is built on the collective wisdom of its members and > community. Having metrics-based projects might be an interesting > experiment, but that's not the ASF. My read of the proposal is that reduces uncertainty for a project attempting to achieve "good health" and discredits any critiques which might be raised by individual humans. Gaming the system can be seen as justifiable if you don't consider the critiques valid and chafe under an authority whose legitimacy you question. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Apache Metrics, Not Apache Humans
Very strong -1 I'm pretty sure the details of my objections will already be covered in the thread (not read it yet, just need to express my very clear objection to this proposal, I'll follow up else-thread if there is anything I need to add beyond my summary below). Summary of my objection: community building is an art not a science, there is no "score" that can be placed upon a community. Ross -Original Message- From: Marko Rodriguez [mailto:okramma...@gmail.com] Sent: Sunday, November 15, 2015 10:20 AM To: general@incubator.apache.org Subject: Apache Metrics, Not Apache Humans Hi, I was talking with Daniel Gruno and wrote the following ideas to him. Note that these are just ideas and not based on any real momentary issue or concern -- though a more general concern about how Apache should evolve. Apache should NOT use a binary "podling" / "top-level" model. All projects should simply have a "health score" and that health score is derived from measurables. Because of Apache Infrastructure's centralized server model (email lists, version control, distributions, homepages, etc.), it has the ability to gather metrics such as, for example, the distribution of pushes to the repository, the branch factor of the mailing list, the centrality of the project in the Central Maven repository dependency graph, the number of non-sequisters (dead-end conversations) in the email chain, the length of discussions in JIRA, etc. etc. Which metrics are important? Who care -- just make up things to glean from the wealth of information you already have access to. Watch... Next, the Apache members subjectively say which projects they think are "good" (healthy). This can even be a global vote including everyone in the world and (should be) dynamic over time as projects evolve with time. Either way, lets say, the ranking says Apache Hadoop, Apache Solr, Apache Commons, etc. are the (collective subjective's) "best" Apache projects. Now, there should exist a multi-dimensional projection of the aforementioned gleaned statistics what will have Hadoop, Solr, Commons, etc. close to one another in metric-space (clustered). Likewise, low ranking projects should be close to one another in this space and far from Hadoop, Solr, Commons, etc. Find that projection and that is your "healthy metric space." >From here, all Apache projects have a computed "healthy" score(s) and when >users go to download, lets say, Lucene, they go: "Cool. This is a healthy >project." (it has a HEALTH.txt file distributed with it, lets say). What that >means is that Lucene, at that release was in the "healthy" cluster of the >metric space. This model has various benefits: 1. There is no need to have philosophical arguments (not grounded in measurables) about what rules a project should follow (bounded by law). - Perhaps a project that is exclusive, but is X is still in the "healthy" subspace. - Perhaps having bad documentation is a "unhealthy" even though Apache doesn't care about documentation. - Perhaps too much discussion causes a project to become "unhealthy." - Perhaps ... who knows? ... let the statistics do the talking. - Apache becomes a breeding ground for different models of open source (bounded by law), not just "The Apache Way." - And these models are measurable! Let us study the act of open source. 2. "Top-level" projects can fall from grace. - Currently, all "top-level" projects are "equal." This should by dynamic as the mighty do fall. - It is possible for what are now "podlings" to be "healthy" as they simply are coming into Apache. - "The student is the master." - Hadoop 1.2.1 might be the healthiest version of Hadoop (as I tend to believe). "Hadoop" is not a thing eternal. 3. Less work for people. - No more VOTEing on graduation. - No more amorphous aesthetic arguments about "The Apache Way." - No more long winded contradictory documentation about how things should be done (bounded by law). The Apache Way should be about metrics, not about philosophy as different paths lead to the same mountain top <--- See! Is that random Buddhist saying that everyone just "believes" even true? :) Get the human out of the loop! Thanks for reading, Marko. https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmarkorodriguez.com&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cdb866066721040907ba908d2ede96bfb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2f0HPyoryrfA
Re: Apache Metrics, Not Apache Humans
On Sun, Nov 15, 2015 at 10:49 PM, Bertrand Delacretaz < bdelacre...@apache.org> wrote: > On Sun, Nov 15, 2015 at 7:20 PM, Marko Rodriguez > wrote: > > ...The Apache Way should be about metrics.. > >...Get the human out of the loop! > > No. > > The ASF is built on the collective wisdom of its members and > community. Having metrics-based projects might be an interesting > experiment, but that's not the ASF. > > -Bertrand > > I was trying to find a polite way to disagree, and Bertrand said it all. Also, we have multiple projects, in different maturity levels (which imply different activity levels), which are just fine for ASF. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Re: Apache Metrics, Not Apache Humans
On 11/15/2015 01:20 PM, Marko Rodriguez wrote: > The Apache Way should be about metrics, not about philosophy as different > paths lead to the same mountain top <--- See! Is that random Buddhist saying > that everyone just "believes" even true? :) Get the human out of the loop! I, for one, welcome our new computer overlords, however ... Metrics are useful for early warnings, but are awful at actually determining community health. I would encourage you to ask our friends at Bitergia, Markmail, Black Duck, and so on, about measuring communities, since they've spent a decade or more each on the science. They'll all tell you the same thing - metrics are incredibly useful, but should be treated with great caution, and always, always, always include a human element in evaluating. Because numbers don't show the whole picture. Many healthy communities have low activity from time to time, or perhaps have community patterns that evade your particular measuring techniques. And unhealthy communities often learn how to game the measures, or are doing unhealthy things outside of the scope of what's being measured. It's a fascinating thought experiment, and, indeed we should always strive to have better metrics, but we must be intelligent - and human - in how we read those numbers. One of the things that separates the ASF from GitHub or SourceForge, is that we do have a unifying philosophy, and a community of humans that defend it. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache Metrics, Not Apache Humans
On Mon, Nov 16, 2015 at 3:12 PM, Steve Loughran wrote: > ...The standard way to test this is run a test workload through the system and > verify the results are as expected. For an ASF project, that'd probably be > submitting a patch and seeing what happened Creating a bot that does that autonomously and reports on the results would be a fantastic research project ;-) -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache Metrics, Not Apache Humans
> On 16 Nov 2015, at 00:28, toki wrote: > >> >> not about philosophy as different paths lead to the same mountain top > > Somebody failed Buddhist Logic 101. (Not all paths lead to the same > mountain top, even if they appear to start at the base of the same > mountain.) And foundational alpine mountaineering: a route that leads to the top may be beyond your abilities —and you may only discover that at a point where you cannot retreat. This is why it is always good to have your own map and never follow the people in front. They may know where they are going, but that doesn't imply its the route you should do. w.r.t metrics, they could be used to detect problems —but systems can look healthy metric wise, yet still be utterly broken. The standard way to test this is run a test workload through the system and verify the results are as expected. For an ASF project, that'd probably be submitting a patch and seeing what happened. -Steve - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache Metrics, Not Apache Humans
On Sun, Nov 15, 2015, at 11:58 PM, Sergio Fernández wrote:
> Marko, the metrics approach has been discussed in the past, for instance
> http://markmail.org/message/ubx3utli3bnltv75 So far my feeling is that
> the ASF prefer to deliver of people to build an opinion of projects rather
> than based them on pure statistical metrics. But I'd be happy to see something
> like that.
Metrics can help people form opinions ("huh, there's been fewer than 5
emails per month on Project Y's dev list ... that sounds like we should
look more closely at that project") but "pure statistical metrics" are a
*horrible* way to decide whether a project is "healthy."
A project could have a very active set of mailing lists, lots of
commits, push out releases regularly - and still be unhealthy in any
number of ways. (e.g. - all of the work is coming from people paid by
one company, or that community is refusing to accept patches from anyone
employed by another company, or any number of other situations that
don't indicate a project that's "healthy" as we understand health.)
Conversely, a project may have minimal traffic, very few commits, and so
forth - but still be "healthy" because it's a mature project that needs
very little development to stay useful and relevant to its community.
Best,
jzb
--
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache Metrics, Not Apache Humans
On Sun, Nov 15, 2015 at 7:20 PM, Marko Rodriguez wrote: > ...The Apache Way should be about metrics.. >...Get the human out of the loop! No. The ASF is built on the collective wisdom of its members and community. Having metrics-based projects might be an interesting experiment, but that's not the ASF. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache Metrics, Not Apache Humans
Marko, the metrics approach has been discussed in the past, for instance http://markmail.org/message/ubx3utli3bnltv75 So far my feeling is that the ASF prefer to deliver of people to build an opinion of projects rather than based them on pure statistical metrics. But I'd be happy to see something like that. Hi, I was talking with Daniel Gruno and wrote the following ideas to him. Note that these are just ideas and not based on any real momentary issue or concern -- though a more general concern about how Apache should evolve. Apache should NOT use a binary "podling" / "top-level" model. All projects should simply have a "health score" and that health score is derived from measurables. Because of Apache Infrastructure's centralized server model (email lists, version control, distributions, homepages, etc.), it has the ability to gather metrics such as, for example, the distribution of pushes to the repository, the branch factor of the mailing list, the centrality of the project in the Central Maven repository dependency graph, the number of non-sequisters (dead-end conversations) in the email chain, the length of discussions in JIRA, etc. etc. Which metrics are important? Who care -- just make up things to glean from the wealth of information you already have access to. Watch... Next, the Apache members subjectively say which projects they think are "good" (healthy). This can even be a global vote including everyone in the world and (should be) dynamic over time as projects evolve with time. Either way, lets say, the ranking says Apache Hadoop, Apache Solr, Apache Commons, etc. are the (collective subjective's) "best" Apache projects. Now, there should exist a multi-dimensional projection of the aforementioned gleaned statistics what will have Hadoop, Solr, Commons, etc. close to one another in metric-space (clustered). Likewise, low ranking projects should be close to one another in this space and far from Hadoop, Solr, Commons, etc. Find that projection and that is your "healthy metric space." >From here, all Apache projects have a computed "healthy" score(s) and when users go to download, lets say, Lucene, they go: "Cool. This is a healthy project." (it has a HEALTH.txt file distributed with it, lets say). What that means is that Lucene, at that release was in the "healthy" cluster of the metric space. This model has various benefits: 1. There is no need to have philosophical arguments (not grounded in measurables) about what rules a project should follow (bounded by law). - Perhaps a project that is exclusive, but is X is still in the "healthy" subspace. - Perhaps having bad documentation is a "unhealthy" even though Apache doesn't care about documentation. - Perhaps too much discussion causes a project to become "unhealthy." - Perhaps … who knows? … let the statistics do the talking. - Apache becomes a breeding ground for different models of open source (bounded by law), not just "The Apache Way." - And these models are measurable! Let us study the act of open source. 2. "Top-level" projects can fall from grace. - Currently, all "top-level" projects are "equal." This should by dynamic as the mighty do fall. - It is possible for what are now "podlings" to be "healthy" as they simply are coming into Apache. - "The student is the master." - Hadoop 1.2.1 might be the healthiest version of Hadoop (as I tend to believe). "Hadoop" is not a thing eternal. 3. Less work for people. - No more VOTEing on graduation. - No more amorphous aesthetic arguments about "The Apache Way." - No more long winded contradictory documentation about how things should be done (bounded by law). The Apache Way should be about metrics, not about philosophy as different paths lead to the same mountain top <--- See! Is that random Buddhist saying that everyone just "believes" even true? :) Get the human out of the loop! Thanks for reading, Marko. http://markorodriguez.com P.S. The same should hold true for educational degrees. I graduate and now forever I'm an expert in computers? Medical doctors too! A 90 year old doctor can do surgery on me?!?!… Binary graduation is not "real." Metrics, metrics, metrics --- we live in a world where this is possible. For every "thing" good comes and goes, up and down…
Re: Apache Metrics, Not Apache Humans
momentary issue or concern -- though a more general concern about how Apache should evolve. I personally think that the complex human emotions is important evolutionary mechanism. The machine or math can't. On Monday, 16 November 2015, Marko Rodriguez wrote: > Hi, > > I was talking with Daniel Gruno and wrote the following ideas to him. Note > that these are just ideas and not based on any real momentary issue or > concern -- though a more general concern about how Apache should evolve. > > Apache should NOT use a binary "podling" / "top-level" model. All projects > should simply have a "health score" and that health score is derived from > measurables. Because of Apache Infrastructure's centralized server model > (email lists, version control, distributions, homepages, etc.), it has the > ability to gather metrics such as, for example, the distribution of pushes > to the repository, the branch factor of the mailing list, the centrality of > the project in the Central Maven repository dependency graph, the number of > non-sequisters (dead-end conversations) in the email chain, the length of > discussions in JIRA, etc. etc. Which metrics are important? Who care -- > just make up things to glean from the wealth of information you already > have access to. Watch... > > Next, the Apache members subjectively say which projects they think are > "good" (healthy). This can even be a global vote including everyone in the > world and (should be) dynamic over time as projects evolve with time. > Either way, lets say, the ranking says Apache Hadoop, Apache Solr, Apache > Commons, etc. are the (collective subjective's) "best" Apache projects. > Now, there should exist a multi-dimensional projection of the > aforementioned gleaned statistics what will have Hadoop, Solr, Commons, > etc. close to one another in metric-space (clustered). Likewise, low > ranking projects should be close to one another in this space and far from > Hadoop, Solr, Commons, etc. Find that projection and that is your "healthy > metric space." > > From here, all Apache projects have a computed "healthy" score(s) and when > users go to download, lets say, Lucene, they go: "Cool. This is a healthy > project." (it has a HEALTH.txt file distributed with it, lets say). What > that means is that Lucene, at that release was in the "healthy" cluster of > the metric space. This model has various benefits: > > 1. There is no need to have philosophical arguments (not grounded > in measurables) about what rules a project should follow (bounded by law). > - Perhaps a project that is exclusive, but is X is still > in the "healthy" subspace. > - Perhaps having bad documentation is a "unhealthy" even > though Apache doesn't care about documentation. > - Perhaps too much discussion causes a project to become > "unhealthy." > - Perhaps … who knows? … let the statistics do the talking. > - Apache becomes a breeding ground for different models > of open source (bounded by law), not just "The Apache Way." > - And these models are measurable! Let us study > the act of open source. > 2. "Top-level" projects can fall from grace. > - Currently, all "top-level" projects are "equal." This > should by dynamic as the mighty do fall. > - It is possible for what are now "podlings" to be > "healthy" as they simply are coming into Apache. > - "The student is the master." > - Hadoop 1.2.1 might be the healthiest version of Hadoop > (as I tend to believe). "Hadoop" is not a thing eternal. > 3. Less work for people. > - No more VOTEing on graduation. > - No more amorphous aesthetic arguments about "The Apache > Way." > - No more long winded contradictory documentation about > how things should be done (bounded by law). > > The Apache Way should be about metrics, not about philosophy as different > paths lead to the same mountain top <--- See! Is that random Buddhist > saying that everyone just "believes" even true? :) Get the human out of the > loop! > > Thanks for reading, > Marko. > > http://markorodriguez.com > > P.S. The same should hold true for educational degrees. I graduate and now > forever I'm an expert in computers? Medical doctors too! A 90 year old > doctor can do surgery on me?!?!… Binary graduation is not "real." Metrics, > metrics, metrics --- we live in a world where this is possible. For every > "thing" good comes and goes, up and down… -- Best Regards, Edward J. Yoon
Re: Apache Metrics, Not Apache Humans
On 15/11/2015 18:20, Marko Rodriguez wrote: > 1. There is no need to have philosophical arguments (not grounded in > measurables) about what rules a project should follow (bounded by law). "Healthy" is intrinsically subjective, and as such, unmeasurable, leading to even more debates as to whether or not a project is "healthy". > Apache becomes a breeding ground for different models of open source (bounded > by law), not just "The Apache Way." "The Apache Way" was formulated for a reason, and not only because it more or less works as designed. Other models of open source have different points of failure, some of them being the equivalent of sepiku on sight. > The Apache Way should be about metrics, The major problem with measuring things, is that the only things that get done, are those that get measured. This is most clearly seen in the bankruptcy of ISO-9000 certified organizations, that won awards for their quality control, and measurement in changes thereof. (In some fields of endeavour, ISO-9000 certification is the first step towards an inevitable chapter 7 bankruptcy filing.) > not about philosophy as different paths lead to the same mountain top Somebody failed Buddhist Logic 101. (Not all paths lead to the same mountain top, even if they appear to start at the base of the same mountain.) > P.S. The same should hold true for educational degrees. I graduate and now > forever I'm an expert in computers? That depends upon whether you went to a vocational/trade school, or an institutional that gave you a real education. (Hint: if you didn't learn the YiJing,TRIZ, and at least seven languages, alongside the seven arts, you didn't have an education.) jonathon signature.asc Description: OpenPGP digital signature
Re: Apache Metrics, Not Apache Humans
> Because of Apache Infrastructure's centralized server model (email lists, version control, distributions, homepages, etc.), it has the ability to gather metrics such as, for example, the distribution of pushes to the repository, the branch factor of the mailing list, the centrality of the project in the Central Maven repository dependency graph, the number of non-sequisters (dead-end conversations) in the email chain, the length of discussions in JIRA, etc. etc. Does anyone have any statistically significant measure that any of those "measurables" define the health of a community? > Which metrics are important? Who care -- just make up things to glean from the wealth of information you already have access to. Watch... "Who care". "Just make up things". WTH. Yeah, I thought not. > Next, the Apache members subjectively say which projects they think are "good" (healthy). > [...] > From here, all Apache projects have a computed "healthy" score(s) and when users go to download, lets say, Lucene, they go: "Cool. This is a healthy project." (it has a HEALTH.txt file distributed with it, lets say). That file should not be named HEALTH.txt, it should be called POPULARITY_CONTEST_WINNERS.txt. What is wrong with, for the most part, allowing communities to define their own success? Why do we have to pick "best"? Why should every project community not picked as "best" by the membership not then respond with an immediate and hearty "fuck you"? I'm sorry, but this reads as a collection of frighteningly terrible ideas that I hope die as quickly as possible. On Sun, Nov 15, 2015 at 10:20 AM, Marko Rodriguez wrote: > Hi, > > I was talking with Daniel Gruno and wrote the following ideas to him. Note > that these are just ideas and not based on any real momentary issue or > concern -- though a more general concern about how Apache should evolve. > > Apache should NOT use a binary "podling" / "top-level" model. All projects > should simply have a "health score" and that health score is derived from > measurables. Because of Apache Infrastructure's centralized server model > (email lists, version control, distributions, homepages, etc.), it has the > ability to gather metrics such as, for example, the distribution of pushes > to the repository, the branch factor of the mailing list, the centrality of > the project in the Central Maven repository dependency graph, the number of > non-sequisters (dead-end conversations) in the email chain, the length of > discussions in JIRA, etc. etc. Which metrics are important? Who care -- > just make up things to glean from the wealth of information you already > have access to. Watch... > > Next, the Apache members subjectively say which projects they think are > "good" (healthy). This can even be a global vote including everyone in the > world and (should be) dynamic over time as projects evolve with time. > Either way, lets say, the ranking says Apache Hadoop, Apache Solr, Apache > Commons, etc. are the (collective subjective's) "best" Apache projects. > Now, there should exist a multi-dimensional projection of the > aforementioned gleaned statistics what will have Hadoop, Solr, Commons, > etc. close to one another in metric-space (clustered). Likewise, low > ranking projects should be close to one another in this space and far from > Hadoop, Solr, Commons, etc. Find that projection and that is your "healthy > metric space." > > From here, all Apache projects have a computed "healthy" score(s) and when > users go to download, lets say, Lucene, they go: "Cool. This is a healthy > project." (it has a HEALTH.txt file distributed with it, lets say). What > that means is that Lucene, at that release was in the "healthy" cluster of > the metric space. This model has various benefits: > > 1. There is no need to have philosophical arguments (not grounded > in measurables) about what rules a project should follow (bounded by law). > - Perhaps a project that is exclusive, but is X is still > in the "healthy" subspace. > - Perhaps having bad documentation is a "unhealthy" even > though Apache doesn't care about documentation. > - Perhaps too much discussion causes a project to become > "unhealthy." > - Perhaps … who knows? … let the statistics do the talking. > - Apache becomes a breeding ground for different models > of open source (bounded by law), not just "The Apache Way." > - And these models are measurable! Let us study > the act of open source. > 2. "Top-level" projects can fall from grace. > - Currently, all "top-level" projects are "equal." This > should by dynamic as the mighty do fall. > - It is possible for what are now "podlings" to be > "healthy" as they simply are coming into Apache. > - "The student is the master." > - Hadoop 1.2.1 might be the healthiest version of Hadoop >
Apache Metrics, Not Apache Humans
Hi, I was talking with Daniel Gruno and wrote the following ideas to him. Note that these are just ideas and not based on any real momentary issue or concern -- though a more general concern about how Apache should evolve. Apache should NOT use a binary "podling" / "top-level" model. All projects should simply have a "health score" and that health score is derived from measurables. Because of Apache Infrastructure's centralized server model (email lists, version control, distributions, homepages, etc.), it has the ability to gather metrics such as, for example, the distribution of pushes to the repository, the branch factor of the mailing list, the centrality of the project in the Central Maven repository dependency graph, the number of non-sequisters (dead-end conversations) in the email chain, the length of discussions in JIRA, etc. etc. Which metrics are important? Who care -- just make up things to glean from the wealth of information you already have access to. Watch... Next, the Apache members subjectively say which projects they think are "good" (healthy). This can even be a global vote including everyone in the world and (should be) dynamic over time as projects evolve with time. Either way, lets say, the ranking says Apache Hadoop, Apache Solr, Apache Commons, etc. are the (collective subjective's) "best" Apache projects. Now, there should exist a multi-dimensional projection of the aforementioned gleaned statistics what will have Hadoop, Solr, Commons, etc. close to one another in metric-space (clustered). Likewise, low ranking projects should be close to one another in this space and far from Hadoop, Solr, Commons, etc. Find that projection and that is your "healthy metric space." From here, all Apache projects have a computed "healthy" score(s) and when users go to download, lets say, Lucene, they go: "Cool. This is a healthy project." (it has a HEALTH.txt file distributed with it, lets say). What that means is that Lucene, at that release was in the "healthy" cluster of the metric space. This model has various benefits: 1. There is no need to have philosophical arguments (not grounded in measurables) about what rules a project should follow (bounded by law). - Perhaps a project that is exclusive, but is X is still in the "healthy" subspace. - Perhaps having bad documentation is a "unhealthy" even though Apache doesn't care about documentation. - Perhaps too much discussion causes a project to become "unhealthy." - Perhaps … who knows? … let the statistics do the talking. - Apache becomes a breeding ground for different models of open source (bounded by law), not just "The Apache Way." - And these models are measurable! Let us study the act of open source. 2. "Top-level" projects can fall from grace. - Currently, all "top-level" projects are "equal." This should by dynamic as the mighty do fall. - It is possible for what are now "podlings" to be "healthy" as they simply are coming into Apache. - "The student is the master." - Hadoop 1.2.1 might be the healthiest version of Hadoop (as I tend to believe). "Hadoop" is not a thing eternal. 3. Less work for people. - No more VOTEing on graduation. - No more amorphous aesthetic arguments about "The Apache Way." - No more long winded contradictory documentation about how things should be done (bounded by law). The Apache Way should be about metrics, not about philosophy as different paths lead to the same mountain top <--- See! Is that random Buddhist saying that everyone just "believes" even true? :) Get the human out of the loop! Thanks for reading, Marko. http://markorodriguez.com P.S. The same should hold true for educational degrees. I graduate and now forever I'm an expert in computers? Medical doctors too! A 90 year old doctor can do surgery on me?!?!… Binary graduation is not "real." Metrics, metrics, metrics --- we live in a world where this is possible. For every "thing" good comes and goes, up and down…
