Hi Stewart, There's no censorship, dictatorship, or conspiracy in this community, but we have gradually grown over almost a year, very productively, because everyone agrees on a certain level of civility and constructiveness in their contributions. When reacting on an issue based on string feelings, it is always wise to pause and consider in turn how others will react to what you say.
Look through the archive. Not a single person has appeared on the list who agrees with your proposal and would join in the effort to develop NuPIC under C4 in the way you suggest. That silence says a lot more than any supposed idea of banning you from the list. Look at your own github fork repo. Nobody has joined as a contributor. You haven't even committed a patch yourself (perhaps because you need one other person to merge it). Watch the Open Office video, where you'll see that Grok will soon be on a stabilisation fork and the community will have a much freer hand than at present. Read Matt's responses to your previous emails. He plans to migrate NuPIC to a C4-based development system once this is feasible (technically first and then "socially"). Read your own email above, look at the language you've used. I don't claim to judge you based on reading a few emails from you on a single subject, and I think it's quite rude to characterise others based on your reaction to their opinions. I certainly see very little evidence of anything you've said about Grok employees, in fact quite the opposite. Regards Fergal Byrne On Wed, Mar 5, 2014 at 3:06 AM, Stewart Mackenzie <[email protected]>wrote: > > >If Stewart reads this, how would you evaluate difficulty of the > >"flow-based" NuPIC? > > Interesting question, not so easy to answer. > > In order not to reimplement the whole messaging wheel, it'll be best to > just use zeromq. This makes it easier, but the hard constraint on > dependency free core puts that to the test in a big way. Thus the probable > outcome is to use zeromq then maybe once proof of concept is sound rewrite > the messaging. This is probably an insane thing to do. Might be best to > just compromise with one dependency. > So depending on the messaging rewrite / dependency hardline - this impacts > difficulty. > > It shouldn't be done as one massive code drop on main. It reworks the > entire structure of each component. Thus each component supports > asynchronous io. > If it is done in one huge code drop, 90% it'll be wrong, integration will > be slow. It'll be fubar. > It would be an extremely rocky ride for Grok, but at this stage API needs > to break so as far as I'm concerned nobody should come along for the ride > but should just wait for the next bus. > > Network ( component graph) manager related stuff needs to be stripped out. > Lots of python related stuff in there. Link class removal etc - difficulty > - "soso" > > Then that very clean asynchronous API needs to be distilled. difficulty - > "hard" - as it requires lots of intelligent and stupid people to bash that > API into shape. > > This should really be done by core team. But there is too much office > politics, ass covering, and ego for them to effectively make decisions > independently, the community has to cause them to reflect, but even then > the 'don't do this on our mailing list' card will be pulled, so expect > blood to flow, and members banned. One needs to remind them, the community > are not employees that need to be managed. There are a subset that behave > like employees, these folk _maybe_ seeking employement. It doesnt mean we > all seek this path, and therefore should model it. On the whole we come to > free software to escape office politics. There is nothing more annoying > than ego trumping good sociotechnical decisions. > > It'll probably be best done by an enthusiastic bright student, but one > shielded to best effect by C4. Then again just using C4 is too much drama, > so I'm giving up being the tip of the spear point effecting change. Need > some nupic R&R before I come back, in the mean time I'm passively watching. > btw now I will no longer hold back my opinions (both technical and > sociotechnical) regarding nupic's path forward even if it includes swear > words and gets me banned! > > I don't have the ability to see a clear path through this, that's why I > need C4. C4 effectively maps a path through the problem space. Its at this > point i need my mind to engage with crowd wisdom. Now, there are too many > variables and possible outcomes. So when people come to me saying are you > sure this is going to work, or I've been backing you, (now I'm scared to > back you) all I can say is: you need to use C4 to effectively map this > problem space. At this time, it means maintainers who implement C4 > _properly_. David being made a maintainer is an _excellent_ step forward. > But I fear it is an appeasement only. The real proof is when David > liberally (guided by C4) clicks the green button, now we're talking. > > Unless core devs bite the bullet, by putting Grok on the side and getting > things done quickly then reattaching Grok. Without using C4 and the ability > to pivot with crowd wisdom, It'll be nearly impossible, or will be a long > series unmerged, closed pull requests. The brush I have used is broad, it > does not touch all. > > Hence my overall answer based on my current naivety level : Impossible at > the moment. > > > > Kind regards > Stewart > > -- > Please excuse my typos and brevity > > _______________________________________________ > nupic mailing list > [email protected] > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org > -- Fergal Byrne, Brenter IT <http://www.examsupport.ie>http://inbits.com - Better Living through Thoughtful Technology http://ie.linkedin.com/in/fergbyrne/ https://github.com/fergalbyrne e:[email protected] t:+353 83 4214179 Formerly of Adnet [email protected] http://www.adnet.ie
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
