Improvements to Bugzilla - Making it easier and simpler
Open, Needs TriagePublic



Our new contributor experience is not as accessible as it could be. Documentation is often out of date, phabricator can be intimidating, bugzilla doesn't offer any guidance on how to file good bugs or direct people to put patches on Phabricator.

As a result, users file a lot of un-actionable bugs that waste our time and frustrate them when they are closed; many enthusiastic and competent programmers don't contribute; and patches on bugzilla frequently languish forever. We should work on guiding new potential contributors.

What it will take

  • Add project-specific templates to the description field for new Bugzilla bugs that gives users information they need to solve their own issue or provide the information necessary for us to actually triage the bug (see
  • Collapse the UNCONFIRMED and CONFIRMED statuses into NEW to avoid confusion
  • Change the WONTFIX and INVALID statuses to something a bit softer so that users who have their bugs closed with these statuses don't feel negative emotions toward it and us
  • Change the attachments page to notify users that patches should be submitted to Phabricator instead, along with a link to a how-to page

How we know we succeeded

  • Bugzilla bugs won't have patches in them that fall by the wayside
  • The volume of un-actionable bugs will slow dramatically and there will be less back-and-forth between developers and users, freeing up bug-triaging resources and turning them into development resources. Bugs will be more valid, better tracked, and not pile up forever
  • More bugs will be accompanies by patches on Phabricator
  • We'll get more new contributors submitting patches on Phabricator

Relevant links

I am willing to put work into this

  • Nate Graham (writing and deploying documentation and the new Bugzilla template and statuses)

I am interested

  • Gregor Mi (@gregormi)
  • Hopefully other people
ngraham created this task.Aug 20 2017, 1:47 PM
lydia moved this task from Backlog to drafting on the Goal settings 2017 board.Aug 20 2017, 1:50 PM

Both T6775 and T6776 are private (even for a community admin)

I added Community Admins to both, but I'm not sure how that happened. Is there anything else I need to do?

Is there a reason why can't they be open?
I would say that those requests, for consistency, should go on, and maybe discussed first (see my previous discussion on kde-community@ about changing few states in bugzilla, which sadly I didn't push further).

ngraham updated the task description. (Show Details)Aug 20 2017, 2:13 PM

I'd love to make them open, but I don't know how. I've just moved them over to

lydia added a comment.Sep 15 2017, 7:27 PM

I am not sure if we should limit this to bugzilla. How about widening the scope to be about improving on-boarding processes and experiences in general?

Sounds good to me!

Are you going to adapt it or should I?

ngraham renamed this task from Improve bugzilla process for new users to Improve contribution process for new users.Sep 30 2017, 4:21 PM
ngraham updated the task description. (Show Details)

I did! :)

neofytosk added a subscriber: neofytosk.EditedOct 2 2017, 12:49 PM

I was working in parallel in this proposal I just submitted, my suggestion is about a more overarching effort relating to the onboarding of new contributors:

I think the two could merge as we go ahead, depending on the outcome of discussions.

lydia added a comment.Oct 2 2017, 6:23 PM

Yeah I think it is a good idea to merge them.

ngraham updated the task description. (Show Details)Oct 2 2017, 7:17 PM
cfeck added a subscriber: cfeck.Oct 2 2017, 8:33 PM

Regarding the 'NEW' status: We used that instead of 'CONFIRMED' earlier, see

'UNRESOLVED' (to match 'RESOLVED') or 'OPEN' is what I would prefer for the merged status.

I mentioned a previous discussion about states in bugzilla, but I didn't link the archives. This is the starting point of the thread:

I don't feel strongly about the word we replace it with, but I do agree that we should combine both statuses into one.

gregormi updated the task description. (Show Details)Oct 3 2017, 9:38 AM
gregormi added a subscriber: gregormi.

I think good and stable bindings to Python (see e.g. can help to attract new contributors. Python is often used in educational contexts. It can be used for quick prototyping, could be used to write small productivity tools with Python/Qt on top of KFrameworks or extending existing applications like Kate with Python-based plugins. This could serve as a low level entry to get familiar with Qt and KDE related technologies.

Hi! my name is Paco and I've started developing for kde two months ago and I'm just getting started... I had worked in other open source project with a smaller scope and, when starting to work with kde what I've missed is:

  • when working in little projects and know someone (specially someone who has experience with the project) get stuck is less common and, when getting troubles, you allways have someone with whom have a relationship to ask often without feel dumb
  • when working in little projects/hackatons you can easily know more people who is starting as you and you feel you're not the only who is a bit lost in the project...
  • when working in little projects is easy to find something you can do and to organice with others to avoid working in the same thing than others, and also is easy to ask 'ey, I'm interesting in this, can you suggest me some issues/tasks to do?' instead of seeing a lot of projects and issues finding something to do.

For these reasons I would like to suggest a dinamic, just for disscus:

We could make 'beginner teams' formed by 4 or 5 beginner and one veteran developer (some kind of mentor) in order to get things more easy. These teams would work arround the mentor ideas; for example, like a mentor, I would like to improve plasma tasks switchers, so I made a beginner team for this and select some tasks from bugzilla/phabricator for beginner who want to work in this with me. Then, people sign up to the team and I start to guide them to solve these tasks. There would be a chatroom in phabricator for the team in order to discurss about what could do each one, beginner could help each others, and the mentor could get things done faster than if he/she works alone.
When things get done, the group could be closed or continue working in other stuff...

What do you think about it?

jsamuel added a subscriber: jsamuel.Oct 7 2017, 4:07 PM

@navarromorales Mentoring is indeed a very important aspect of improving the contribution process and it can help solving issues like the ones you describe.

I know KDE participates in external initiatives like Google's Summer of Code and Code in, but I don't recall seeing something specifically coming from within. So a suggestion here could be towards KDE becoming more systematic in terms of mentoring and organizing its own events related to it.

So, what do we do with this proposal and now? They are so similar that it really makes little sense from my perspective to keep them separated.
Can @ngraham and @neofytosk maybe see how to proceed with merging them into one which contains all aspects of both?
Otherwise votes would end up split between the two, effectively reducing the chance for either of them to be selected.

@colomar I strongly support the merge. I just added that would also apply to this ticket. So what shall I do? Link it? Repost it here aswell? Or wait for the merge? ;)

neofytosk added a comment.EditedOct 20 2017, 1:11 AM

Yup, totally agree with merging as these two obviously overlap. Am just not sure if and how merging can be done through phabricator without all the current comments being lost.

If that is not possible, we could start a new ticket to do this. As T7116 is more general in its spectrum, my suggestion is to import T6832 into T7116 as a subsection specifically on coders and bugzilla. Then add a comment including all the relevant comments from both proposals, of course attributing everything accordingly. It would look like this: Do let me know if I missed someone/something!

If @ngraham and the rest here agree, I can go ahead and do that.

@neofytosk Sure, I'm fine with that.

Please do merge. The comments will still be available in the ticket that is marked as a duplicate. And it will be linked from here automatically when you merge it in.

neofytosk renamed this task from Improve contribution process for new users to Improvements to Bugzilla - Making it easier and simpler.Thu, Apr 5, 7:20 PM
neofytosk reopened this task as Open.
neofytosk updated the task description. (Show Details)
neofytosk added a comment.EditedThu, Apr 5, 7:31 PM

In regard to UNCOFIRMED/CONFIRMED status, there's a relevant discussion here:
And more about bugzilla's usefulness here:

I've replied to those threads hoping to get the discussion started again so we can implement the changes we find are more suited for our developers' workflow.

Feel free to add further sub-tasks for specific topics/suggestions relating to this.

And more about bugzilla's usefulness here:

A main point of the discussion in this thread was that we should clean up Bugzilla through removing old & unmaintained products. I just did some basic searching and found 120+ products which had Unmaintained / Deprecated / Replaced by in their summary. There are probably even more products which are unmaintained since multiple years. I think it would be quite helpful to remove these from the "Browse" list in bugzilla. If wanted, I can sit down & filter out all unmaintained or deprecated applications in the next few days.