Matthew Fulmer Board agenda
Posted 27 Feb 2008 by tappleCommunity
Squeak is not just a tool to build and deploy software. It is a community of people who believe that our ideas are worth pursuing and spreading. We share ideas via a variety of media, but the vehicle by which our ideas come to fruition is the code we touch.
My name is Matthew Fulmer, and I am campaigning for a position on the Squeak Foundation Board. To me, my big goal is to nourish and defend the squeak community: nourish it by fostering communication among it's subgroups, and defend it by giving internal and external critics fewer things to complain about.
Fostering Communication
From the time I joined the Squeak community in September 2006, I have been trying, in my own small way, to get information flowing more freely among the diverse members of the community.
I first joined because I saw great potential to use EToys in my research lab. I had no immediate needs I could fulfil with Etoys, and no new projects I could start in Squeak, so I was unsure how to go about learning it. So I took a sugestion from Benjamin Pollack on irc and started writing documentation. I started up the Squeak Documentation Team and got a few noobs like myself together, and we tried to get a tutorial going, but we didn't really know how. I mostly worked with the Swiki from then until June 2007, gathering and reviewing tutorials so that other noobs would be able to find the best tutorials to learn Squeak. As I hung out on #squeak, I got to know lots of people, and really began to love the community. I tried to help by do what I could to clean up the Swiki. I didn't really learn to program in Squeak until June 2007. In July, I decided that Documentation wasn't the best way I could help out the Squeak community. The biggest issue I was seeing is the lack of code review and discussion. So I spent two months learning how to code squeak and made a patch to SqueakSource that would send emails out whenever a new package version was uploaded. I hoped this would lower the barrier to reviewing code by making changes more visible. It has not yet accomplished that, although the patch was added to squeaksource.com a few months ago. I realized at that point that we are lacking in tools to discuss, review, and document code patches, and that it is limiting our effectiveness at moving forward. One major consequence of this is that bugs tend to get fixed in one fork of squeak and remain broken in o ther forks because either no one knew it got fixed, or because we only accounted for the bug once. SqueakSource commit emails was my first attempt at alleviating the problem. DeltaStreams is my second.
Another area where communication is lacking is between the board and the greater Squeak community. I spend a lot of time on #squeak irc sharing ideas with noobs and veterans, who are often in ignorance about the doings of the board. I would continue to spend time with the community as a board member, and I would help raise awareness of issues between the board and the greater community.
Fixing Bugs
Bugs are anything that prevents squeak from working how it should. One big bug the previous board has gone to great lengths to fix is the confusion regarding Squeak's license, which keeps many people from easily downloading and using squeak, due to linux distribution policies, and keeps other smart people from contributing to Squeak because of license incompatability with their home project. I am trying to understand the problem and how to solve it through my informal "Squeak release" meetings. Being on the board would give me greater exposure to the problem, and, hopefully. a better understanding of what that means for the Squeak release.
Another major bug is the lack of functional teams. Since the inception of the board, there has not yet been an example of a functional team, except maybe the News Team. We need a team to look up to as a model, and a good place to start is the Release Team. For this, we must decide on a spec for the release and follow it through with a schedule (not necicarilly with dates, but with a breakdown of tasks that will be completed before the release is done). If deciding that is impossible, we must choose someone who will do that and give them full respect and follow their spec. Edgar, Jerome, or Keith may be good candidates for such a job. The problem is that none of the interested parties are Project Managers, but programmers. The board needs to make sure this happens.
Conclusion
The three big things I want to see happen this year in squeak are:
- establish forums for the sharing of code and ideas between our various sub-groups
- establish a spec for the release
- finish the relicense
[ Home | Articles | Login/Account | People | Projects ]