« Return to Thread: [KDE Usability] 100 Papercuts Like Project
Re: [KDE Usability] 100 Papercuts Like Project
by Bugzilla from hanswchen@gmail.com
::
Rate this Message:
This is a great idea. I've wanted to do something similar, but ultimately came to the conclusion that I didn't have enough time to pull it off. Since there are others with similar interests I might as well throw my idea out here.
The fundamental difference compared to David's suggestion is that mine is a long-term project rather than short-term. The first step is to set up a forum at forum.kde.org similar to KDE Brainstorm. Here users can post "Papercuts" (or whatever we decide to call them), vote on those that affect them, discuss etc.
The forum should be strictly moderated and a papercut has to be approved before making it into the list, similar to how Brainstorm works now. This requires a few dedicated moderators who have a good feeling for what a papercut is.
Developers and other interested people can then pick papercuts they want to fix from the forum. For example, you can sort by the most popular papercuts by vote, or get a list of random papercuts. Of course we could also do campaigns from time to time, e.g. "Fix the top 100 papercuts during this week".
Here are some advantages of the forum approach:
- The forum is more friendly to most users compared to Bugzilla. It's also visually pleasing since you can put screenshots etc. directly in the post (you have to upload them somewhere else though).
- The KDE Community Forums already have a large user base and users can use their identity.kde.org account to log in.
- I don't know how it works on bugs.kde.org, but in Brainstorm everyone with a KDE Developer account can mark ideas as Done etc. Requesting a developer account is very easy.
- You can create a custom RSS feed for papercuts you're interested in (again, not sure how Bugzilla works here).
- We can customize it, for example, only allowing voting up (in Brainstorm you can vote both up, down and neutral).
For this to work, we would need:
- Moderators who can approve and moderate papercuts.
- Awareness among users. This is probably quite easy - the forum has many users and I already know quite a few who find small things in KDE Software that are annoying and would like more polish.
- Awareness among developers. This is harder, especially to make developers actually use the tool. Most importantly, it shouldn't be seen a Yet Another Bug Tracker.
For this kind of thing I think a lot of non-devs (myself included) would be interested in contributing. The papercuts should be easy to fix, and there's an immediate impact even if it's small. Therefore I think it would be good with some tutorials about how to get trunk/master running, how to change the code and see the changes, and finally how to submit patches, as part of a "campaign".
Those are just some thoughts I had. Note that I'm not the one who can do all those changes to the forum, so I can' promise that it can be done. However, if there's enough interest, I think it's possible.
With best regards,
Hans
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability
The fundamental difference compared to David's suggestion is that mine is a long-term project rather than short-term. The first step is to set up a forum at forum.kde.org similar to KDE Brainstorm. Here users can post "Papercuts" (or whatever we decide to call them), vote on those that affect them, discuss etc.
The forum should be strictly moderated and a papercut has to be approved before making it into the list, similar to how Brainstorm works now. This requires a few dedicated moderators who have a good feeling for what a papercut is.
Developers and other interested people can then pick papercuts they want to fix from the forum. For example, you can sort by the most popular papercuts by vote, or get a list of random papercuts. Of course we could also do campaigns from time to time, e.g. "Fix the top 100 papercuts during this week".
Here are some advantages of the forum approach:
- The forum is more friendly to most users compared to Bugzilla. It's also visually pleasing since you can put screenshots etc. directly in the post (you have to upload them somewhere else though).
- The KDE Community Forums already have a large user base and users can use their identity.kde.org account to log in.
- I don't know how it works on bugs.kde.org, but in Brainstorm everyone with a KDE Developer account can mark ideas as Done etc. Requesting a developer account is very easy.
- You can create a custom RSS feed for papercuts you're interested in (again, not sure how Bugzilla works here).
- We can customize it, for example, only allowing voting up (in Brainstorm you can vote both up, down and neutral).
For this to work, we would need:
- Moderators who can approve and moderate papercuts.
- Awareness among users. This is probably quite easy - the forum has many users and I already know quite a few who find small things in KDE Software that are annoying and would like more polish.
- Awareness among developers. This is harder, especially to make developers actually use the tool. Most importantly, it shouldn't be seen a Yet Another Bug Tracker.
For this kind of thing I think a lot of non-devs (myself included) would be interested in contributing. The papercuts should be easy to fix, and there's an immediate impact even if it's small. Therefore I think it would be good with some tutorials about how to get trunk/master running, how to change the code and see the changes, and finally how to submit patches, as part of a "campaign".
Those are just some thoughts I had. Note that I'm not the one who can do all those changes to the forum, so I can' promise that it can be done. However, if there's enough interest, I think it's possible.
With best regards,
Hans
On Wed, Nov 2, 2011 at 15:24, Ernesto Manríquez <alejandronova@...> wrote:
2011/11/1 Albert Astals Cid <aacid@...>:
1. Albert, we already have those users. They usually bitch around> A Dimarts, 1 de novembre de 2011, David Edmundson vàreu escriure:
>> > Do you expect maintainers of applications where bugs are found to fix
>> > them themselves or rather us providing patches?
>>
>> What I was thinking was, we generate some buzz and create a public bug
>> list, people who read our blogs make patches and send them to the
>> relevant application teams through the normal processes.
>>
>> All we do is publicity and count the number of "papercuts open/closed"
>> on a website. Maintainers just have to review any patches coming in,
>> or they can fix their own stuff if they want to.
>>
>> (Plus I'd get involved in doing some of the fixing :-D)
>
> What i fear from this kind project is the user that will request something
> silly but that for him is the most important feature/change in the world and
> and then will make extreme noise if the suggestion is rejected by the
> maintainer.
>
> Of course this is not a suggestion not to do the project, but to have this
> kind of user in mind and be proactive to try to make them less of a problem.
>
> Albert
>
>>
>> Dave
>> _______________________________________________
>> kde-usability mailing list
>> kde-usability@...
>> https://mail.kde.org/mailman/listinfo/kde-usability
> _______________________________________________
> kde-usability mailing list
> kde-usability@...
> https://mail.kde.org/mailman/listinfo/kde-usability
>
about how KDE doesn't listen their user base. They don't contribute,
and they are best ignored, just like they are ignored now.
2. However, the real possibility of users like me proposing usability
enhancements, along with the real chance they will be worked on and
eventually integrated into the Software Compilation, is extremely
awesome. I have some usability quirks on my list that shouldn't take a
long time to quash.
3. We must be clear about our procedures.
a) Let's open a defined term (a week, for instance) to make users
propose usability quirks to the dev team.
b) A dev must filter the proposals, according to the following criteria.
- They must be doable quickly (less than x hours of dev time)
- They must not require fundamental changes to the code.
c) If there are too many proposals passing the filtering, let's select
them through a poll until they reach the number of 100.
d) Assign those papercuts to the dev team or to students team under
the SoK program, according to their complexity.
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability
« Return to Thread: [KDE Usability] 100 Papercuts Like Project
| Free embeddable forum powered by Nabble | Forum Help |
