********* TARGET ********* WHAT WE WANT TO GET - The Ubuntu experience to be a pleasure. HOW WE WANTED IT TO BE LIKE, IN DETAIL - Bug management to be agile and simple. - Unable to find small flaws in the desktop. - Have the impression the desktop is rock solid. - Feel that the Ubuntu desktop usage experience is the most reliable of any operating system. - Feel the Ubuntu usage like a toy. - Getting involved in Ubuntu development to be a nutshell for children. - Ubuntu to reflect the best of libre software and modern computing. IN WHICH MOMENTS WE APPROACH MORE THAN THE USUAL TO WHAT WE WANT - When we center in work rather than in planning. - When holding communication to minimum. - When documentation in wiki is simple over complete. - When it is discussed before. - When processes are under a well planning. WHAT WE DO DIFFERENT UNDER THESE CIRCUMSTANCES - We focus in getting work done. - We focus in things to be simple. - We complete our points of view with other's. - We identify what is actually really important. - We ask ourselves how much value the work been done is inducing. WHAT THOUGHTS WE HAVE WHEN DOING THIS - That work is what makes real feedback with reality. - That simplicity is what really makes you know you're doing right. - That all of us together are the greates knowledge power. - That working just in the most important thing is what makes commits easy. - That we want is the true reference. WHAT ELSE THINKS WHO IS SUCCESSFUL HERE - That people who created everything around you is not smarter than you. - That doing the kind of things that works, it does for everyone. - That trusting in the above is what is important. - That doing better is not about working harder, but to be able to get it right by working less. - That only the 20% of work that gets the 80% of worth is the really important one. - That you'll never get tired of working in something that makes sense to you. - That working in what you feel is of value is what will make you to distinguish, although you don't know why in the beginning. - That uncertainty is natural when taking targets never done before, and assuming it is the difference between who dreams about it and actually gets it. - That leadership is just taking work others are scared off. - That he isn't what he thinks or does: it just does it because he wants it. - That is natural that people rather believe in their points of view, because are these of what they will have always a better level of detail of. - That with simplicity comes beauty, and beauty reflects potential. - That everyone knows what knows, and doesn't know what doesn't know. - That all together know much more than a genius itself. - That trust is the greatest interpersonal prize, and transparency is what creates it. ********************** REMAINING ACTIONS ********************** # "[o]" tag means "available to be worked on". # "[x]" tag means "awaits a previous action to be completed, so don't touch". # "[v]" tag means "action finished (and you can review it)" # You can help with any of these actions, and you can write your name without spaces as tag if you need nobody to touch the piece of work you took. # You can modify this list as you find it is needed, but keep finished actions: the project coordinator will delete them when needed. # For shared information, create wiki pages in wiki.ubuntu.com (remember to delete them some days after if needed), and paste its link under the title. WE REBRAND THE PROJECT TO FIT DESIGN.UBUNTU.COM - [o] We make the heart of the project logo to be a transparency instead of white. - [o] We redesign the "Papercuts Ninja" logo. - [o] We redesign the "Papercutters" team logo. WE REDEFINE WHAT A PAPERCUT IS - [o] We expand the definition of papercut to include any package with a valoration of four or five stars, with at least of 20 reviews, in the Software Center. - [o] We reduce the definition of papercut to not include by default packages in Kubuntu. - [o] We reduce the definition of papercut to not include packages with a priority of "whislist" or "critical". - [o] We reduce the definition of papercut to not include packages where the affected package is "Linux". - [o] We reduce the definition of papercut to only include packages tagged with the latest release name, and the one under development. WE EDIT OUR WIKI - [o] We make the content of the wiki to be simple and make sense to any audience (children, elders and girlfriend included: http://www.philoking.com/2009/01/10/what-is-an-average-computer-user-classic-linux-user-thinking/) - [x] We mention that papercuts are usually easy to fix by developers, so the big work is all done by no programmers. - [x] We make clear that anyone can contribute. - [x] We explain how to perform steps in https://wiki.ubuntu.com/FutureOfThePapercutsProject#A8._Emphasise_the_quantity_and_importance_of_non-developer_roles, in diferent wiki pages. - [x] We include how to search bugs that are prone to the different steps of bug management. - [x] We include how to easy identify bugs that could be potential papercuts. - [x] We mention you can ask the mail list in case of doubt. - [x] We include reference to resources that can help to learn to develop. - [x] We Mention that critical bugs cannot be papercuts. - [x] We Mention that a status of "opinion" can mean there is disagreement on whether or not it is actually a valid paper cut. - [x] We include information that comments in bug #1049082 suggest me. WE EDIT DESCRIPTIONS - [x] We make project description to be simple, attractive to colaborate, and properly linked with teams. - [x] We make "Papercuts Ninja" team description to be simple, attractive to colaborate, and properly linked with the project and the "Papercutters" team. - [x] We make "Papercutters" team description to be simple, attractive to colaborate, and properly linked with the project and the "Papercuts Ninja" team. WE REVIEW OTHER WIKIS - [o] We add pages in wiki.ubuntu.com that shall mention the papercuts project as tasks under this one. WE FILE LIMITATIONS OF LAUNCHPAD AS BUGS - [x] We list limitations of blueprints in Launchpad. - [x] We file limitations of blueprints in Launchpad. - [x] We ask people to comment in limitations of blueprints in Launchpad. WE COMMUNICATE THE PROJECT TO DEVELOPERS - [o] We list teams e-mails in Launchpad that will be interested in knowing this project. - [o] We list teams e-mails outside Launchpad that will be interested in knowing this project. - [o] We list corporations e-mails that will be interested in knowing this project. - [o] We list universities e-mails that will be interested in knowing this project. - [o] We write the e-mail that will be send around the world. - [x] We ask for a week the information to be reviewed. - [x] We send the e-mail to all the listed directions. - [x] 60 days after, We delete the unused wiki pages. WE COMMUNICATE THE PROJECT TO MEDIA - [o] We list media that will be interested in spreading that this project has been redesigned for been easy to get involved in open source. - [x] We list the medium of contact that will be used for contacting every media. - [x] We asociate medias with the same type of medium of contact.