On Thursday 23 October 2003 08:02, digital ch wrote: > You can't have it both ways. The developers want a large group of people > to test with. That means those of us who want to support the project may > opt for reduced functionality. That doesn't mean we should be completely > surprised by changes. I don't care if you make changes that break the app, > what I care is when you intentionally make drastic changes and don't warn > the user ahead of time. > > I'm in development, and I have users that verify my product in a QA > environment. If I make changes that I know will seriously change the > environement without warning them first I catch a world of crap. Why? > Because I wasted their time while they tried to figure out what was going > on, emailing, bug tracking, etc. The key point here is that they have to > be notified in advance so they can plan accordingly. I think many of the > complaints started today originate from that. The users would have > preferred to know what was going on so they didn't upgrade if they didn't > want to take the risk. > > Developers suck at prioritizing and documentation both. I know I was a > developer, now I have lots of them working under me. Want proof? Show me > where there is one really good developer grade piece of documentation on > freenet? You can't cause it doesn't exist. The reason more developers > don't work on this project is because it is obscenely complicated and there > is no really good documentation that tells you the architctecture so that > you can figure out what you should do to start working on a particular > piece. Would it really be so hard to put together a document that says > here are what the major classes are, here is what they are doing, here is > where we need work? If you believe people really want to read through the > source to figure out whats going on your wrong. I want to know exactly > where to focus my attention. Then once I jump in at the appropriate spot I > will dig into the source and go to work. I don't want to read 500 pages > worth of source to figure out the spot I should start work. > > I say this realizing that we have other priorities. (Getting freenet to > work for instance) But it's one of those wierd economic issues. Maybe if > we did a better job with the little things we would end up with more > resources and we could bang out the bigger things quicker... > > Toad, and all the other devs don't feel I'm trashing you. Anyone who works > that hard on a project where people are always complaining and making > suggestions(self included) gets my admiriation. I'm sure it has to be > infinitely frustating. > > I've experienced that to. It sucks I agree. If you ever work under a real > PM/Architect and it will change how you view these things dramatically.
I agree that most of the problems that people are complaining about result from people not knowing what to expect or what they can do. We have a open jobs list for the developers, but it is not updated often, and most of the actual development discussion takes place off this list. Also user are seldom warned whether a new build is likely to break and/or if it is worth their time to upgrade. Finally the webpage has very little documentation on it. It is hard for someone to find out information on how freenet works, even though it is there if they look hard enough. I think all of these problems could be solved if we had someone specifically trying to address them. Because I have been to occupied to become involved in development and will be for the forseeable future, and I would like to contribute to the project, I would like to volenter for the position of 'Development cheerleader'. I have been using Freenet for a long time and have a very solid understanding of how it works, so I think I could easily do this. Basically I would ask all the developers to periodically send me an E-mail telling me: what they are doing, any bugs that they have found and not fixed, and what needs to be worked on. Then I will periodically send a message to this list that gives a status update. Then I will post a simplified version of the same to chat with each new version. If I get time, and was granted access to the websight I would upload more technical documentation. How does that sound? _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
