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 
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.
- What I wish WineHQ should do more of is point 14 from Toyota's production system.
http://en.wikipedia.org/wiki/Toyota#The ... ion_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 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
..................................................................................................................................................................................................................
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.
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.
I just have a gut feeling that something isn't quite right regarding the Wine project. Not on the coding layer but on the project management layer!