Re: KDE 4 problems highlight shift from community users to consumers
Posted by: Anonymous
[ip: 84.55.88.109]
on July 17, 2008 02:07 PM
Hi!
When I started to learn about linux one of the great things I learned was the modularization of things and the customizability as well. This is offcourse a good thing it means you can connect diffrent projects or small apps and get new ones or apps with new features if for example a project stops developing. The negative side of this is offcourse the problem new users find when trying out linux and looking in a distros repo just to find alot off strange names and unfamiliary apps. Also the sheer mass off availble apps is hard to grasp or know witch apps to use and witch are good choices.
As the reasons behind the KDE 4 projects recieval I say it is because of two things.
First NEVER ever do big landings of new technology\code it usualy never gets recieved well by new users especialy when it is something that is seen by the users. UI persistancy is crucial if you gonna change do it very slowly over long period of time so that users can smoothly and suddly be familiarised with the changes and so that your user experience testers can get feedback and inform develpers of their findings. Because u do have UI\HIG testers and apointees dont you if you dont get them asap they are the best qa u can have before new releases. Ooops that was my nuber two thing alwasy use UI\HIG tests done before new releases even just an knoledgeable person responsible for it can do alot of things to shape the project up to expectations.
Thirdly release often and release on time. If u only make small changes then u can do this without any problems just look at the kernel develpment and ubuntu offcourse. This means if one feature didn't make it into this release it can make it into the next that aren't far away.
nuber four on my lis5t is never use a bad numbering scheme when releasing. For example when releasing KDE 4.0 it implies a big change sure it might be that this marks the completion of a long development effort but if you have released often and on time with 3.5, 3.6, 3.7 and so on with small improvments the 4.0 release wont seem dangerous and wont seem like such a big step even if it is and you know it this is were the pr and marketing part of your project must make an effort to show the improvements made over time. and explain the develoment modell. Also never put in unfinished code or unstable in releases to distros if people realy want the newest new let them come and get it themselves. Also use the beta suffix when pre release code is concerned.
Well thats all from me.
Learn about Linux
Download Linux
Get Linux help
Re: KDE 4 problems highlight shift from community users to consumers
Posted by: Anonymous [ip: 84.55.88.109] on July 17, 2008 02:07 PMWhen I started to learn about linux one of the great things I learned was the modularization of things and the customizability as well. This is offcourse a good thing it means you can connect diffrent projects or small apps and get new ones or apps with new features if for example a project stops developing. The negative side of this is offcourse the problem new users find when trying out linux and looking in a distros repo just to find alot off strange names and unfamiliary apps. Also the sheer mass off availble apps is hard to grasp or know witch apps to use and witch are good choices.
As the reasons behind the KDE 4 projects recieval I say it is because of two things.
First NEVER ever do big landings of new technology\code it usualy never gets recieved well by new users especialy when it is something that is seen by the users. UI persistancy is crucial if you gonna change do it very slowly over long period of time so that users can smoothly and suddly be familiarised with the changes and so that your user experience testers can get feedback and inform develpers of their findings. Because u do have UI\HIG testers and apointees dont you if you dont get them asap they are the best qa u can have before new releases. Ooops that was my nuber two thing alwasy use UI\HIG tests done before new releases even just an knoledgeable person responsible for it can do alot of things to shape the project up to expectations.
Thirdly release often and release on time. If u only make small changes then u can do this without any problems just look at the kernel develpment and ubuntu offcourse. This means if one feature didn't make it into this release it can make it into the next that aren't far away.
nuber four on my lis5t is never use a bad numbering scheme when releasing. For example when releasing KDE 4.0 it implies a big change sure it might be that this marks the completion of a long development effort but if you have released often and on time with 3.5, 3.6, 3.7 and so on with small improvments the 4.0 release wont seem dangerous and wont seem like such a big step even if it is and you know it this is were the pr and marketing part of your project must make an effort to show the improvements made over time. and explain the develoment modell. Also never put in unfinished code or unstable in releases to distros if people realy want the newest new let them come and get it themselves. Also use the beta suffix when pre release code is concerned.
Well thats all from me.
#