I mostly agree with Chris on this one, some comments added below. > Michael, > > Thanks for your criticism. I have taken several days to think about > it. I have not discussed my thoughts with the board and I am > speaking only for myself and to my own relationship to the project. > > I agree with you that there are some technical problems with how the > renaming was done; in particular, changes of variable or object names > in the source is unnecessary from a branding standpoint and > unnecessarily destabilizing. It's possible we could revert those > mistakes and perhaps we should. I think Jeff has responded to these > thoughts too.
As Chris described all of the work on LinuxCNC is done by contributors (I consider contributors people who write code, write documentation, test things, etc). This work is done by each individual mainly because they wish to add something to the project (or fix something that is wrong, missing, whatever). They do it without beeing instructed or compelled to. As a result, the people doing the work, are the ones who get to decide on what they want to work, how they want to do it, etc. Surely if a contribution is seen as negative to the project (by other developers), it can be discussed or even reverted. The authority for this relies still to contributors (most likely contributors which have experience in that particular field). The board (as it is now) doesn't get involved in such matters. If you say it should, then we should discuss it, and change the attributions of the board when a concensus is reached. As for the rename: sometimes discussing a new feature (like a rename) will lead to an interminable discussion with arguments on a couple of sides about how things should get done. This usually leads to a lot of talk and no real implementation. Jeff (as a developer) took the other possibility and jumped right into the change. As a board member I have no real oppinion about the way he chose (except maybe to see that he achieved the goals of renaming the project so as to comply with Emc inc.'s demands, maybe even exceeded them a bit). As a fellow developer (although my developer hat is pretty wrinkly from sitting in a closet) I agree with his later email describing some of the things he could have done better. (that doesn't mean that I wouldn't have possibly made the same mistake if I started the rename). > But this is a very small part of the dissatisfaction expressed in your > letter. Mostly you are dissatisfied with all aspects of the board's > behavior. > <snip> > But aside from that, I see that we have a fundamental disagreement > about the role of the board. The things I think the board should > handle are something like this: > > Represent the project in general to the outside world, being a > point of contact for companies, lawyers, etc. As stated in the current bylaws > Keep tabs on the infrastructure the whole project needs, make > smart decisions about it, and keep it working. This is stuff > like the DNS, the key used to sign the apt repositories, the > websites, arrangements with services that recognize our > project somehow like sourceforge and freenode and the Linux > foundation, and so on. Missing from the bylaws, should probably be added. > This task also includes things like > studying/advocating/implementing the switch from cvs to git. > It also includes deciding in general how we use vc (merging > strategy, stable release branches, feature branches) and > trying to keep people doing that properly. Right, but this should also be done consulting the active contributors (it's not a simple board decision that needs to be accepted as in #1 - represent the project in general...). > Maintain the set of keys from pushers and offer push access to > contributors who show consistent quality and express an > intention to stick around for a while, and hopefully a bit of > guidance to new folks on using vc correctly, the stuff I > mentioned above. > > Select release managers that can help a branch become stable > and eventually get released (so far these have been board > members, but I think they don't need to be). Again, the board can select managers out of developers who are willing to take the role (and volunteer for the task, knowing what it involves). We cannot assign a certain developer as the release manager for 2.6.x without having the certainty that person is up to the task, has the available manpower, is willing to do that job, etc. > > I value your great contributions to the project and am sorry > that you don't have the guidance you want. For example I hear you > talking about a task/interpreter restructure that you are interested > in, and that you have made some progress but want feedback. When > you get no feedback I understand that you can't tell if it's because > nobody cares, or because nobody feels qualified to help you in that > way. In the case of me personally, it's the latter. I'm not an > expert in object oriented design and it does no good for you to tell > me about your design. I have no useful input. <puts wrinkly old developer hat back on> I did some work on the task manager, and my 2 cents are: "most likely any replacement will be an improvement to the current state of things". But I must go with Chris on the rest, design for OO is a lot more rusty for me than my wrinkly developers hat ;) </takes hat back off> <sniped the part about the rebrand decision> I completely agree with Chris on his thoughts. > I think it will be valuable, after this discussion about what we want > the board to be, to have a new election, as we are certainly overdue. > The discussion about the board's purpose may help determine who will > and won't run. I think that is a good thing. Perhaps we can update > some bylaws that are out of date (or out of touch) to reflect what > we collectively think the new board should do. Or, on the other end > of the spectrum, if we feel the board serves no important purpose, > maybe we should disband it and be entirely community-driven. I'd also like to address one of your points which Chris missed: "> btw: what are the intended board terms of service?" Currently the board is to be elected yearly. The current board is thus long overdue for a new election, but there are some reasons it hadn't happened in such a long time (last election was 2009, next one due was 2010): 1. there wasn't much interest in the last election: "With 1047 ballots distributed and 97 returned, the result of the voting is as follows..." 2. there wasn't much activity for the board to justify the hassle for a new election (exception with the current rebranding) (you can look at http://wiki.linuxcnc.org/cgi-bin/wiki.pl?BoardOfDirectors for activity) That beeing said (hopefully it came out as I intended it to sound - but english is not my native language, so please excuse potential mistakes), I hope we can talk towards a common understanding what the board should be, and what kind of people should be part of it (e.g. developers, documentation writers, users, industrial connected people, forum admins, etc). Regards, Alex ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
