Ok, the numbers I got were from Thom's original posting. But even if everyone did an average of 10 installs, it's still a huge number for 5 people to support.

I didn't say you had written it, I said you were responsible for it.

My other comments stand though. You guys work hard, we know that. You guys feel under-valued, well so would I. BUT you guys (whether you like it or not) don't make it easy for people to join you. There shouldn't be a "rite of passage" for new devs. Even if we assume my 10 average installs, that's still 11200 users, and 5 devs. I simply don't believe that only 1 in 2240 users can become a useful developer.

We're knocking on the door offering help, but you aren't letting us in

Ok, the numbers I got were from Thom's original posting. But even if everyone did an average of 10 installs, it's still a huge number for 5 people to support.

I didn't say you had written it, I said you were responsible for it.

My other comments stand though. You guys work hard, we know that. You guys feel under-valued, well so would I. BUT you guys (whether you like it or not) don't make it easy for people to join you. There shouldn't be a "rite of passage" for new devs. Even if we assume my 10 average installs, that's still 11200 users, and 5 devs. I simply don't believe that only 1 in 2240 users can become a useful developer.

We're knocking on the door offering help, but you aren't letting us in

Look its not about 'paying your dues' or needing new Devs to do a 'rite of passage'. We need experienced developers who can dig into the code and get up and running under their own steam. That is totally not to say that a new Dev wont get help and assistance from all of us...but we dont have the time to 'train people' to be Devs. We need people who are further down the road than that I'm afraid...its not a criticism of anyone its just a practical fact.

Ok, the numbers I got were from Thom's original posting. But even if everyone did an average of 10 installs, it's still a huge number for 5 people to support.

I didn't say you had written it, I said you were responsible for it.

My other comments stand though. You guys work hard, we know that. You guys feel under-valued, well so would I. BUT you guys (whether you like it or not) don't make it easy for people to join you. There shouldn't be a "rite of passage" for new devs. Even if we assume my 10 average installs, that's still 11200 users, and 5 devs. I simply don't believe that only 1 in 2240 users can become a useful developer.

We're knocking on the door offering help, but you aren't letting us in

Look its not about 'paying your dues' or needing new Devs to do a 'rite of passage'. We need experienced developers who can dig into the code and get up and running under their own steam. That is totally not to say that a new Dev wont get help and assistance from all of us...but we dont have the time to 'train people' to be Devs. We need people who are further down the road than that I'm afraid...its not a criticism of anyone its just a practical fact.

Andrew

Brief consideration:

Like most of the guys around here I don't have the required level of competences in order to be considered helpful.

As it seems that no spoons are allowed, it looks like I have to dive into the code, bang my head by myself, and find my way around.

Assuming that for a guy like Thom (that was starting surely from a competence level much higher than mine) it took a couple of years to study the code and become a full blown LMCE Dev, I think that for me it should be wise to double such timeframe.

So if I start now, maybe in 4 years I will be suitable to LMCE Project needs. Say in 3 years, because I'm an optimistic guy.

If you're fine with this, so this thread can stop right here.

If not (and I guess you're not fine with this), we have to find a compromise.

We all know that the project needs very skilled, experienced, creative, smart developers to jump in exactly like every other huge project on this earth.Unfortunately this is not happening to LMCE, and considering the estimated time to climb the learning curve it looks like it won't happen soon.

It sounds like anyone that is asking for training is considered too lazy, while the point is that if you let people to learn by themselves they will reach a good skill when probably the project has died already.

So what are we going to do? Wait for a miracle to happen, keep on giving sarcastic answers to anyone that at least shows some good will to be helpful, or try a different approach?

ThxMarco

Logged

tmoore

Each of the 5 devs at the moment is overworked and overstressed. I get that. This overwork is stopping less experienced newcomers from entering the effort because the learning curve is just too high, and there is not enough support (especially in the form of documentation and organization of efforts) coming from the 5 devs. This is a vicious cycle that needs breaking.

Let me be clear what I'm talking about when I say management. I'm talking about dividing an conquering. I'm not talking about people being just "managers" and not contributing in any other way. I'm talking about people taking a leadership responsibility for one specific, and hopefully small, area of the effort. They may be the sole leader in that space, or others may join them, but they will coordinate. They will be the "go to guy" that has the time and knowledge to introduce newcomers to that area of the development and ensure that it is documented sufficiently. These team leaders need to coordinate with each other towards a common goal - which must be defined and agreed. This is rational organization of a large project, and it is the only way it will succeed.

This organization was not needed to start with, but now the code base and user base have grown to a size that means it is a must. It's a classic evolutionary step. We are walking a well trodden path.

I may be a management consultant now, but that came out of 12 years hard slog managing the production of software applications. So, I recognize these problems, and it is why I'm trying to point them out and help. I have seen (and in my less experienced days, have been responsible for) projects failing due to overworked and overstressed developers with not enough coordination or vision. I've also seen projects fail due to a focus on making beautiful code, but with not enough attention to what the customers/users actually want.

How to we break the cycle? Short of raising funds to pay for resource, the devs need to acknowledge that they must lower the barrier to entry. The most effective way to do this is to stop development work temporarily, and for everyone to focus purely on documentation for a while (and some of the newcomers can probably help with this too). There then has to be a transitional phase where newcomers can try themselves to get up to speed, but where the devs must expect to have to give a certain amount of support (and that support should have priority over their own coding). But then, the manpower will be able to grow exponentially and we'll more than make up for the short pause for the documentation and training effort. The organization into smaller teams will allow more and more people to contribute, and the product will be a shining success.

I for one think the newbie documentation is a bit weak. Not kicking anyone, but it is not as logical as it could be for new guys and the wiki contains lots of "out of date" information.

I think we are at the stage that we can archive most of the wiki and keep the entries that are valid for 810 onwards. Most of the other linux communities have had to go through a similar process over the past year or so (look at the DVB / V4l wiki at the moment), and are better for it. Lots of posts are newbie simple questions (of which i have posted my fair share) because the information isnt as obvious as it could be. As mentioned in the wiki thread I am more than happy to rememdy this side of the documentation and also pull togeather a more newbie friendly install guide. I also feel a list of supported hardware (even if its just the setups of the big 5 devs then it would be useful). Clearly we can all contribute to hardware that is working but we need to guard against "plug and play" comments when it turns out you actually have to do quite a lot of work to get the hardware working (my Kworld USB card is a good example under 810!).

There's a sticky FAQ post that would be a good place for you to start with a new-user wiki page.

To anyone that has shown interest in a particular area: I think we've gotten past the point of discussion and are on the task of getting some work done! For example, I'm already working on new orbiter graphics and putting together a LMCE icon repository. If you want to help document, start making an outline and post it. As more people join in, everyone can flesh it out.

The only thing that is going to impress anyone now that all has been said is action.

A break down of exactly what each component of the code does and is responsible for, and how they link together... even a single line for each would be a vast improvement and provide a skeleton for others to expand on... this doesn't exist at all at the moment...

"Media Plugin - responsible for accepting media manipulation commands such as MH Play/Stop, creating stream objects for the house....""Xine_Wrapper - an instance for each MD, responsible for receiving media manipulation commands from Media Plugin, and playing media on each MD....""DCE Router - DCE protocol routing hub, all DCE devices connect to this device, and use it to relay DCE commands, events, etc to all other DCE devices in the house...""AppServer - one instance per MD, responsible for MD volume levels, spawning new DCE devices(?)....""MD device - one instance per MD, 'virtual' object acting as a parent object for each MD to which you can relay DCE commands which will be passed on to each child device on that MD...."etc...

Once we have that, we can then link from each 'device' entry, and detail each .cpp .h etc that are used to implement each device, what each is responsible for and so on. Even relatively simple devices like PSS are composed of _many_ pieces of code, and it is far from clear even from the name of each .cpp exactly what it does....

Whatever we think about people being 'lazy' for wanting this information, and whether that is objectively a fair or true assessment.... if this documentation existed, people _would_ start getting involved. Lets not get hung up on if it is or isn't lazy for people to want this information.. if it existed, people would be doing work on the project.... who cares if they are lazy or not, all we are really interested in is getting hands on the project and if this is the way to do it... then so be it!!

Yes, I agree completely. If we are to become an OS success story, we need a product that just works. A massive goal I know, because of the complexity of the thing. But this should be our first major goal. New features can come after that (and let's be honest, that's quite enough as it is).

I am a complete Newb, and am thus only suitable for bitch work, but I'm sure in a product such as LMCE, there's going to be a large call for that.

I'm sure the devs must get bored of hearing this, but OMFGWTFBBQ you lot are good. I mean, Really, REALLY good.

Okay, I propose the following goals, in order of importance:

1. It just works. For everyone, all the time (obviously with exceptions)2. The UI becomes unified throughout.3. Plug-ins, and supporting architechture.4. Updated UI (A little less 2000)

Obviously 4 is a long way off, and it should be. All efforts should go towards 1 for the moment, as I can guarantee we'll have a huge infux of people when that is completed. Who's with me?

A break down of exactly what each component of the code does and is responsible for, and how they link together... even a single line for each would be a vast improvement and provide a skeleton for others to expand on... this doesn't exist at all at the moment...

"Media Plugin - responsible for accepting media manipulation commands such as MH Play/Stop, creating stream objects for the house....""Xine_Wrapper - an instance for each MD, responsible for receiving media manipulation commands from Media Plugin, and playing media on each MD....""DCE Router - DCE protocol routing hub, all DCE devices connect to this device, and use it to relay DCE commands, events, etc to all other DCE devices in the house...""AppServer - one instance per MD, responsible for MD volume levels, spawning new DCE devices(?)....""MD device - one instance per MD, 'virtual' object acting as a parent object for each MD to which you can relay DCE commands which will be passed on to each child device on that MD...."etc...

Once we have that, we can then link from each 'device' entry, and detail each .cpp .h etc that are used to implement each device, what each is responsible for and so on. Even relatively simple devices like PSS are composed of _many_ pieces of code, and it is far from clear even from the name of each .cpp exactly what it does....

Whatever we think about people being 'lazy' for wanting this information, and whether that is objectively a fair or true assessment.... if this documentation existed, people _would_ start getting involved. Lets not get hung up on if it is or isn't lazy for people to want this information.. if it existed, people would be doing work on the project.... who cares if they are lazy or not, all we are really interested in is getting hands on the project and if this is the way to do it... then so be it!!

Colin this information is in plain sight in the Wiki... and has been for ever... see Thom's post above. If people moaning about lack of docs can't even look in the most obvious of places for the information...then it tends to suggest that maybe they should do a little homework before being so 'vocal' in this thread about lack of docs.

I agree with tmoore. It should be good project management to successfully release new versions of LinuxMCE. We should create a development team with some hierarchy, have team leaders (current developers who work with 0810 can/should be them), have clear project management (we have users with such experience). We shouldn't re-invent the wheel. Let's see how other open source projects are organized - MythTV, KDE, Gnome etc. Otherwise we may loose our project. Because the number of tasks is growing and a few persons physically cannot implement all of them. Personally I'm very appreciated to all who work hardly with 0810. This is a really great job!

I agree with tmoore. It should be good project management to successfully release new versions of LinuxMCE. We should create a development team with some hierarchy, have team leaders (current developers who work with 0810 can/should be them), have clear project management (we have users with such experience). We shouldn't re-invent the wheel. Let's see how other open source projects are organized - MythTV, KDE, Gnome etc. Otherwise we may loose our project. Because the number of tasks is growing and a few persons physically cannot implement all of them. Personally I'm very appreciated to all who work hardly with 0810. This is a really great job!

Look...project management is not whats lacking here...believe me. We need real software developers who really can write code - period. Its really simple...What we dont need is some corporate like structure with loads of people 'managing'. If anyone contributing to this thread or reading it can offer those types of skills...then stop posting in this thread and get started.