Now that 18.04 is out and developers are moving their attention to the agenda for 18.10 (and a new pre-LTS cycle starts), is it an idea to revive the “100 paper cuts” idea (see also https://en.wikipedia.org/wiki/Paper_cut_bug and https://launchpad.net/hundredpapercuts). I remember it fondly from the 2009/2010 cycles and it seems like an appropriate time to revive it. I can think of a number of reasons why:
- The big change from Unity to Gnome is maturing, necessitating the need to focus on smaller things to improve the experience.
- The enthusiasm and excitement created in the community has created momentum, from a PR and development perspective reintroducing the 100 paper cuts could help sustain that momentum
- Having moved from Unity to Gnome myself (and going back and forth several times) I cannot help but noticing many small annoying things that could contribute to upstream and thus help the ecosystem as a whole
5 Likes
Papercuts, BugSquad, Launchpad, Community, Mailinglists - there are too many loud words, but many bugs are not fixed for years.
Bug examples with high Heat:
Ubuntu should change the logic behind LaunchPad.
You released 18.04 LTS with completely broken Scilab (missed Java, broken ATOMS, scilab closes immediately when launched from GUI).
The bugs were reported, but there is no reaction from developers and maintainers.
May be it was too late? But when it will be on time?
Nautilus like the whole GNOME is castrated and not user-friendly. For example RedHat tried to make it better by shipping GNOME Classic session.
What will be next?
As I understand that the times of Ubuntu 6.06 when the community was dominated exclusively by professionals passed. In this community come newcomers, who are damn tired of MS Windows. They just want to do their work and that the software is stable.
What can be done now, so that a minimum amount of time passes between the error message and its correction? Perhaps you should establish better contact with upstream.
1 Like
I also remember this and have been thinking about it too - Great idea @wpieterson 
Another keyword(s) here would be lowhanging fruit.
It makes sense that Canonical prioriteres their time to work on crucial bugs. I admit that I sometimes (still) find the entry level for contributing too high, for my technical skills, but luckily there are some awesome people in the community that can help.
It would be great if there was a list with easy tasks (like the GSOC).
3 Likes
What the hell is scilab?
Other than that 18.04 had a better out of the box experience than 16.04. I would even say it was a pretty damn good start.
The only crucial bug I fear to happen again every day is the GDM bug.
On topic, I don’t understand what that’s all about? The most annoying bugs/issues/problems are the ones that need deep knowledge of gnome shell and mutter imho 
Would be great to have more people step up and fix bugs ofc! 
1 Like
Also don’ t know what scilab is and, to be honest, I’d love for this discussion to be productive and positive, if the community rejects the idea of doing a 100 papercuts cycle, fine with me. Even though I am not a coder, I can help out in different ways, such as organise lists and orchestrate efforts.
Also; the 100 paper cuts project was never meant to ignore the bigger bus, but simply to refine the experience and correct the smaller things that, no doubt, will surface as people start adopting 18.04 en masse. Some things, in my experience, that could be considered these are (for example):
- Needing to install some packages in order to get the gnome extensions website to function. These should probably be included from the start.
- On my ThinkPad, the login screen on boot is not showing the right resolution, afterwards (on lock) the screen is fine. This looks like a relatively minor Xrander issue
- There’ s a lot of Suru icons missing in the Communitheme. This is not necessarily a technical bug, but definitely something that with some polish could improve the experience in 18.10 (and an area where I can help).
- I am also experiences some bluetooth issues that seem mostly due to config problems rather than actual code problems.
- The new welcome screen on my laptop was loading incorrectly (i.e. it was hiding behind the dock)
- I also have the issue where upon hiding and revealing the dock the desktop icons get messed up (although this fits in the broader discussion regarding icons on the desktop).
All relatively small issues that could improve the experience and, without any doubt, will affect more users and other users will experience similar smaller problems, whether they have to do with UI / UX / or the technical stuff.
So this is meant like an initiative for the community to pick one or two minor bugs and see if they can fix them on their own?
I think this sounds interesting, I just don’t fully understand it. 
1 Like
Yes and no. Yes, it is meant as an initiative for the community to pick up an handful of bugs. But no, it is more than that. When Ubuntu did the 100 paper cuts, it created a lot of interest in the (broader) community, which basically helped do a number of things:
- Create a clearly defined set of ‘paper cuts’ that would greatly help the Ubuntu experience, in stead of the more scattershot approach that is common. This helped create focus. Project groups tend to work more effectively if there is a clear set of goals (in stead of a seemingly endless list of to do’s).
- The PR around the initiative, irc stimulated a lot of people to actually submit ideas and report bugs, this (obviously) helped in creating a more valid picture of where the issues are (see for example how @d0od paid attention to it on OMG!.
- The attention around it attracted people willing to fix issues, in other words, it helped reinvigorate the community and it seems like we can use that again right now.
I think it’s a great idea although a little ironic that there are currently 821 items on the One Hundred Papercuts bug list. 
Many of the items tagged for the attention of the Paper Cuts team are very old. The oldest dates back to 2004 and was still being commented on 10 years later. That surely was never a “paper cut”. 
@wpieterson, I think any revival of the project should involve revisiting the bug list and remove items as they become dated or deemed too difficult to fix by the team. It’s very easy to add bug reports to the list but items need to be reviewed and/or removed so as to concentrate efforts on a manageable number of bugs.
2 Likes
I totally agree. I don’t think the current list is being taking very seriously by anyone. In that sense I would almost be inclined to start anew and clear the list. Maybe we could do something like:
- Ask the community for their experiences and (small) annoyances
- Go through the bug list on Launchpad and identify paper cut bugs
- Go through reviews at assess the expert’s opinions and their experienced issues
Combine that with some PR around the initiative and we might be able to go somewhere.
3 Likes
100 paper cuts was all about flagging bugs that should be easy for newcomers to work on and start contributing to Ubuntu, this by definition means it does ignore the bigger/harder bugs, it was meant to be a list of the low hanging fruit, not super hard to fix bugs. Also It was never something that majority of Ubuntu developers track, it was afaik an seperate community project intended to attract for contributors to Ubuntu.
1 Like
yes, I think you are mostly right. Although initiatlly it was not about getting newcomers to work on easy bugs, the goals was a bit more high level (improve the experience by reducing paper cut bugs; i.e. relatively small bugs with a (relatively) big impact (hence the name). That did include a call for newcomers to step in and fix those bugs. In my view a revived 100 paper cuts approach should target multiple goals at once. For the sake of repetition these are:
- Improve overall usability of Ubuntu, specifically aimed at the next LTS (20.04), but for now targeted at the 18.10 cycle and beyond.
- Attract new talent to the community (developers, designers, translators, etc), by creating a positive momentum
- Tighten the ties with the community. show how a community driven project can get stuff done, i.e. showcase in a coordinated effort how a community driven project (together with Canonical) do awesome things.
1 Like
@wpieterson, please no, there is way to much creep in that. I have been involved for ~8 years (most for Ubuntu GNOME) and IMO Canonical have picked up their community involvement a lot in the last 12 month.
100 paper cuts (or similar) should be either focused at developers or focused at newcomers, but certainly not both.
- All the Canonical (and community teams) will be focusing on 18.04.1, backporting fixes as possible until then (July) , I don’t think anyone would intentionally be waiting on 20.04 to push fixes back that far unless they require a massive engineering effort.
- From my experience as tech lead for Ubuntu GNOME you probably want different projects to cover the different contributors. It is impossible to think a single project such as 100 paper cuts could cover all those things.
- Havent Canonical done this to a good extent with commuititheme, snaps etc, and going back further they were helpful with the Ubuntu GNOME requirements, just that wasnt so public since it was a small community team compared to Ubuntu proper.
Call me naive, but why would there be creep in that? I see a lot of your points (e.g. the priorities of the community and Canonical, and the (sorta) dichotomy between newcomers and experienced developers). However, I also signal things such as:
- For normal users (that are often even less technical than I am) filing bugs is a hassle (that often results in technical mumbo jumbo). I have filed many bugs in my time using Linux (since ~2006), but even I am put-off whenever Apport starts yeling at to ‘Report a problem’ (the notion that reviews recommend getting rid of it is telling, see https://fosspost.org/tutorials/things-to-do-after-installing-ubuntu). The point here is that the current infrastructure for filing ‘paper cut bugs’ could be insufficient and a paper cut project could mitigate that (to same extent, admittedly).
- There is virtually no easy way for ‘simple’ users to submit ideas (that could be related to bugs, but at the very least could improve usability) . Should I go to the community website and then register and then open a topic only to find out that it will get buried in no time? Should I go on Launchpad? Or do something else? Hurdles are high and people are lazy (and yes, I am not a developer, but I do know a thing or two about human behavior), so getting their input at this point is not easy.
Furthermore, I am not propagating starting something new that will conflict with existing ways of working or hindering the existing practices of developers. What I am advocating is creating an infrastructure to solicit feedback from actual users, turning that feedback into an organised list and presenting that list to the community where a) newcomers can step in and help out and b) existing developers might learn a thing or two about how users are using the tools they are building.
Anyway, it is just an idea and I am offering my help, if the community says ‘no’; fine with me.
creep as in the you are suggesting the 100 paper cuts project becomes the be all and end all of what could be 100 facets of Ubuntu.
The Canonical devs work on what they think is important, the community devs work on what they are interested in, how is that a dichotomy?
I am not trying to knock down your ideas, but expecting that everyone can have input and that all ideas will be implemented is a downward spiral, Try and make it better, sure, but there has to be some threshold involved, even with the power of open source there is no chance of fixing all the individual bugs, that in some cases only affect a few users.
1 Like
Developers are working either in their free time as volunteers or are paid by their companies to work on Ubuntu, but Ubuntu does not have a massive developer team. Some bugs will remain unfixed, we’re going to have to live with that, getting annoyed at it doesn’t help unless we turn our annoyance into productivity. I propose than rather lamenting about the situation on here and giving generic suggestions like ‘better contact with upstream’ (Ubuntu are silver sponsors of GUADEC, the GNOME conference, for example, and do contribute upstream and the Bug Squad are supposed to file bugs upstream when they’re ready) we just do what we can to file and triage bugs (to make things as easy for the devs as possible) and let the devs do the rest in their own time or become devs ourselves. I don’t think that we can do anything other than that @Norbert and complaining on here will just make everyone more frustrated, grouchy, and unproductive.
What does this mean, what are your specific proposals? Have you filed (Wishlist) bugs against Launchpad for your proposals?
With the Scilab bug, for example, you(?) forwarded upstream, but upstream hasn’t fixed the bug, so it’s still bugged in Ubuntu, that’s not really Ubuntu’s problem - Ubuntu simply doesn’t have enough developers to fix every bug in every piece of software. Really, the bugs need to be fixed upstream (and Ubuntu devs will help with that as they are able to do so) and then the fixed versions will get into Ubuntu and will be backported/SRU’d to earlier releases if appropriate.
Have you filed specific gripes with GNOME and Files on GNOME’s GitLab? I filed a bug asking for a return of the status bar (I don’t actually want it back but was forwarding a bug from Ubuntu’s Files bug tracker) and the Files lead actually admitted that he thinks that the current floating bar situation isn’t ideal. If you raise specific suggestions on their bug trackers they might actually agree with you or they’ll give good reasons why they reject certain ideas I submit, though, that you might prefer to just run Ubuntu MATE or Kubuntu if you really hate the GNOME paradigm, but I don’t think it should stop being default, you might want to make a separate topic for that, but there are those who really love GNOME Shell and/or who love Ubuntu’s modified GNOME. Not everyone agrees with you here.
Keep filing bugs and forwarding them upstream (when appropriate) and triaging bugs as you have done and encourage others to do the same. That’s all we can do
1 Like
I haven’t done much with the One Hundred Papercuts project but I agree that any new initiative should instead just continue the previous one. I also wonder exactly how useful this is for onboarding new contributors and whether it’s time that should instead be spend on the usual Bug Squad tasks (Triaging bugs)… Maybe some time should be put, however, into filtering down the current 400+ list to 100.
Al right, idea submitted, not getting much positive response. Let’s close this topic and move on. Cheers.
I’m positive 
but if there’s no momentum around this project, you’re right that we should just move on.
The advantage of 100 papercuts compared to going to the bug page on Launchpad, is that here you’ll find exactly 100 low hanging bugs, that you can start working on without any/much code experience. Launchpad gives you one million bugs and it’s a bit off putting.
I would suggest a clean slate - one hundred NEW papercuts for 18.10 (or maybe even less).
@ads20000 has a good point that the bugs need to be Ubuntu specific and if they are upstream related, we just need to do the same work upstream - it all comes back down
Another way to contribute would be to pick an app and help squash bugs for that. I would really like to work on the Software Center (I know it isn’t actually called that anymore, but you’ll know what I mean) in this cycle, because I think it’s absolutely essential that it’s fit for fight - it’s something many users, especially newbies, interacts with. All of that work will be upstream and flow down to all the distros including Ubuntu.
3 Likes
I very much like 100 paper cuts as it enables non-programmers (like me, recently retired Cyber Security Chief) to tackle items in their areas of expertise and/or experience. I could not fix all the 18.04 LTS guest sessions security challenges - but I was able to contribute a temporary solution ‘HOWTO remove access to all the users folders by guests’. We also discussed here the great temporary solution of 'hanging on to Ubuntu 16.04 if we needed guest sessions rather than abandoning (the AWESOME) Ubuntu. I fully trust Ubuntu and/or the Ubuntu community will fix guest sessions before 16.04 LTS support runs out in 3 years. The folks on this community have been great and I sure do appreciate and enjoy it.
1 Like