On Sat, Mar 15, 2008 at 11:38 AM, jingo811 <wineforum-user@xxxxxxxxxx> wrote: > > James Hawkins wrote: > > > > How can you judge anything about the Wine project, including project management, if you are not a part of the process yourself? > > Don't take offense, but your views, by definition, are ignorant. > > > > -- > > James Hawkins > > Because I'm a non-ignorant-judger :D > No offense taken and it's not my intention to accuse those who have worked on Wine since it's beginning. > My biggest wish is to see Wine project become the number 1 open source project in the entire world. If you do it without my help even better. But I sense a disturbance with this project and want to improve it by finding out where the problem lies. > That's why I'm so eager to learn C quick-like-grease-lightning and get into the process myself doing some simple bug tracing. Once I manage to get this far pointing out problems in a constructive manner will be easier for me, as of now I have no constructive way to express myself. :( > > There might be a quicker way to reach that constructive level without me having to learn C and WinAPI if I could only watch in real life how the elite coders and the contributors interact with each other and how the management interact with the community. Reading the mailing lists doesn't really reveal the subtle info I'm searching for. > > > .................................................................................................................................................................................................................. > > > > > James Hawkins wrote: > > If you're expecting someone to hold your hand and tell you exactly what to code in this project, you're going to be very disappointed. > > > > My previous posts might seem like I want WineHQ to hold my hand the entire journey like you have described it. Which would be a destructive habit for future Wine coders. But the idea I want to test does indeed sound like what you've described but there's a twist to the idea I want to test. > > Correct me if I'm wrong but haven't WineHQ had problems in the past keeping coders on the project because they lost motivation originating from lack of patience and experience? > If future generations of Wine coders drop like flies because the bar was set too high wouldn't that mean that something isn't done right? Which means there's an opportunity to improve things for the better. > The developers don't set the bar high; the project itself demands it. The learning curve is steep, and hacking on Wine requires a lot of patience and diligence. Trust me, we constantly are bringing new people into the project and trying to push them up the curve, and while we've gotten a few up the hill quickly, most aren't cut out for this level of work. > What I wish WineHQ should do more of is > point 14 from Toyota's production system. > http://en.wikipedia.org/wiki/Toyota#The_Toyota_Production_System > > Me myself have to improve on > point 12 (genchi genbutsu) in order to express myself with a more accurate and constructive language. > > Also I think you are overloading the experienced Wine coders > point 4 (Heijunka) that's why you need to setup a "smart and unconventional" teaching environment where inexperienced C coders and total newbies can grow and learn my osmosis the reward will be more constant if this can be done more smoother. > My definition of learning by osmosis, the implementation on WineHQ will naturally be done differently: > > > When we first learn how to speak, we learn from being around other people and simply picking it up by repetition--by osmosis--from people who already know how to speak. Most of us do not have to go to school to learn our native language. We simply pick it up because it is all around us. It doesn't matter what the language is: English, French, Chinese...if it is what everyone else is speaking, we automatically pick up the basics when we are children. > I understand what you're getting at, but the responsibility lies in the hands of the 'newbies'. Very rarely do we get a new developer that jumps into the project and works there way up the learning curve, with or without asking for help. > > I wish for WineHQ to see these issues by themselves and deal with them more actively and quickly. So I don't have to spam you guys with my endless ranting [Wink] > > > .................................................................................................................................................................................................................. > > > > > James Hawkins wrote: > > > > Working on Wine is different than working on most other projects. > > There is a design plan, but we have no access to it. We're blind men feeling our way through a maze with our hands (the test suite). Even if a developer knew the solution to the problem, it would take much longer for him to guide you through implementing that solution than for him to just implement it himself. > > > > You guys should make a "Wanna be a Wine coder" link at the very top of the WineHQ website. Then as Step 1 or Chapter 1 you should explain what you just described to future Winde coders more detailed. > > And you guys who already understand this difference compared to most other projects should try and point 14 from Toyota's production system. > Searching for methods to do this smarter I'm sure there's more answers to this equation if you found a different and fresh formula to work with. > > Sadly I can't help you much with this department as it requires Code Manager status to see this kind of complexities. But I'm hoping you guys could brain storm on it and improve it for future generations. Me just a simple non-ignorant-judger. > No it doesn't. Our development process is completely transparent. Discussions occur on wine-devel, patches are sent to wine-patches, and the committed patches show up in wine-cvs. Users are helped in wine-users. What are you thinking is going on behind 'closed curtains'? > > James Hawkins wrote: > > > > If you really want to work on this project, just start somewhere...do something. No one will tell you what to do, and reading books only goes so far. > > > > Shouldn't you guys centralize all the sub-projects instead of spreading your Wine coders and contributors like shot gun fire by decentralizing the workforce. Laser focus makes outsiders see results much quicker. If people don't see the effects of their work more quickly then they are going to loose interest and let the fire within themselves die out. WineHQ needs to help newcomers fuel the fire within themselves more actively in order to maintain constant speed on this ship. > No, if everyone worked on the same sub-project, no one would be able to get anything done. The way we work now, we sort of have unofficial maintainers of sub-projects. Each developer then becomes an expert in his subsystem and efficiently fixes bugs in his area of expertise. That isn't to say that we each have exactly one are of expertise. 'Outsiders' can't see the results, because they don't know what they're looking at. -- James Hawkins
