Good that finally there is some winds blowing here. Christopher Lenz kirjoitti: > Christian, > > first off, thanks a lot for this great response! > > Am 10.09.2007 um 16:26 schrieb Christian Boos: >> Christopher Lenz wrote: >> >> The point is that at the time when I was working on those changes, >> nobody really seemed to be interested enough to give feedback, so >> trunk >> was for a while a working area which I used to build "a better >> Trac" in >> an incremental way. It's now easy to say "if there were no feedback, >> then you shouldn't have integrated the changes", but this would have >> applied to /most/ of the changes. Often the distinction between a >> newly >> introduced feature and a bug fix is difficult to make (e.g. the whole >> WikiContext thing was introduced in the first place to address >> existing >> issues), so never introducing any change which didn't get any feedback >> would have led to a status quo, which I didn't want. Instead, I >> preferred to make the changes, at the risk of taking criticism >> afterwards. > > I fully understand that the lack of involvement of team members like > myself plays an important role in how we got here. In my defense I > can only say that I was frustrated at the time about some of the > changes being made. Sometimes frustration paralyzes, and that of > course doesn't help at all. This is basically me breaking out of that > paralysis and trying to start being constructive again :P > > That said, I think there were still too many changes done too quickly > without seriously trying to trigger discussion on this list. And > complaining about a change after it's been made is harder than when > it's still a proposal. So for the future, that's something that we > should try to avoid. > > But let's not talk about spilled milk...
Cat's can drink it still.. :D Few things comes to my mind to prevent this: planning and sticking with a plan. See down... >>> 3) Added bloat > [snip] >> Mea culpa, I certainly went down that slippery slope of adding >> features >> in a too liberal way, or rather, in a way that *I* thought would >> benefit >> the user. That leads to the question of who ultimately has the last >> say >> on each and every big and little design issue in Trac. If someone >> (you) >> thinks that e.g. the timeline links are distracting and useless and >> someone else (me) thinks that they have a real value (like the ability >> to put a change in context, in this case), whose opinion should >> prevail? >> Not to mention other issues where the disagreement comes down to a >> choice of colors (ok, I slightly exaggerate here, but not by much). >> Adding a configuration switch is not an answer, neither can "just >> create >> another plugin" be one, as we are in the end talking about things that >> are done in the core. > > I think in these cases we (a) need to keep the Trac motto of being > minimalistic in mind, and (b) only add features for which there's a > consensus in the team (+0), or even active support by other members > (+1). If there's a feature that someone else on the team thinks > should not be added, there needs to be discussion, and if in the end > there is no agreement, it should not be added. I don't see how we as > a project can work otherwise. > > On a related note, we've now evidently reached a size and state where > we need to write down some basic rules on this decision making process. Decision making is really important thing. Someone needs to be in charge, even this is open project. A bit more mature projects have usually regular meetings - there final decision making team (usually main contributors) decides (votes) what will be included. And sticks with that. For help of decisions, some ticketing systems have end user vote for critical enhancements. Like you can always have three tickets you want contributors to concentrate. One "problem" I see is that over time features were added, added and even more added. And release date is moved always to forward future. Still, planning what will be done for releases and specially sticking with that decision helps to reach goal. We here at work have few very mature products that are still developed actively. Twice a year we have user meeting where we show proposal about several enhancements (usually around 10 to 15) what would be in next release some of them are our own fancy ideas, some of them are requests from end users. End users are allowed to select (or vote) top five or four they want to have. And then we do it. Rinse and repeat. About twice a month someone in our support department goes through all open enhancement/bug reports. Reports are always handled by someone immediately when they arrive, but action might not be done. Like if it's feature request we might just ask for more info, illustrations and such and later produce some proposal. Democratic voting. After vote is passed, results are recorded. As an alien in Trac world it seems that most of API decisions, new features were decided in behind closed doors or even ad hoc manner. Someone just felt it would be cool and in it goes. >>> So that was me venting. I hope I didn't upset anyone too much, and >>> that I made my point of view reasonably clear. >> ... and it's a reasonable point of view to have. >> >> Now I think this analysis misses one big part of the picture: what's >> also gone wrong on the road to Trac 0.11 was that there could really >> have been a bit more contributions given to the project by its team >> members. I certainly don't claim having done all the work and >> assuredly >> some of it would have been better spent in a more focused / inspired >> way, but all in all, if at least someone else had put an equivalent >> amount of work in ticket triaging, troubleshooting, bug fixing >> (including for the 0.10 line), giving feedback, testing, then Trac >> 0.11 >> would already have been released since quite some time. > > I would like the emphasize that I think the amount of work and time > you've put into Trac has always been a tremendous boon to the > project. I don't think anyone doubts that. > > The other side of the medal, though, is that with one person able to > contribute a seemingly infinite amount of time and resources to an > open-source project, getting involved may at least seem harder for > others (committers and potential contributors alike). The same could > be said of myself when we were around the 0.9 mark. It's probably no > coincendence that we're having this discussion at a point when you've > seriously scaled back your activity on Trac ;-) This is one real problem in any open source project. Projects tend to grow and grow and becomes an endless timesink for contributor(s). Finally happens that major (or even only one) contributor will step down and recession begins. It seems really inevitable. -- Jani Tiainen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
