Solve bugs on a timeframe depending on the priority

I also think it's very important the users are not treated as consumers. We
already want to take part and help the project. The worst thing to do is to
ignore reported issues. It would be a million times better even to just say
"No, this will not be fixed because of ..."

Trisquel's development as a whole should be made as transparent as possible.
That way everybody can see who's doing the work and join in, if they have the
skills. I would think quite a few free software hackers have their eyes on
Trisquel. Such a time bank scheme would be at least an interesting
experiment. On the other hand sometimes such external rewards have been
reported to act as disincentive, like when a children were rewarded for
playing they ended up playing less.

These are things that must be addressed to make Trisquel as resilient,
democratic and good as possible.

I don't have a response to your suggestion, but it relates to something
that has been bothering me: we really need to improve communication and
co-ordination within this project.

I understand that quidam is really busy and that we don't have many (or
any other?) people working on core development. I also know that there
are people who are willing to help with things.

Most of the time I don't really know what is going on with the project.
For example as you mentioned, how exactly bug issues are managed. But
there are other things like what exactly happens during development. I
couldn't find any page that gives a "development roadmap". I know about
the Roadmap wiki page, but it does not mention anything worthwhile. I am
also aware of the "Brigantia Development" wiki page, but that felt more
like a bug tracker page than really a roadmap. Maybe others don't care
too much, but it would be nice to have posts giving an idea of what the
progress is, like "Now we are going into XYZ development" or similar.
Firstly, so that we have an idea of the schedule but also in case
somebody wants to help with a specific phase.

Then there are also other non-development things that need
communication, like the member keychains for example. I know that some
setbacks have been discussed on the mailing list but the last reference
I have is from about a month ago. I still have no idea if they were
actually sent out. Again, it would be nice if such things could be
mentioned on the website.

I am not criticising to be negative or ungrateful, but I think this is
important. Basically, if quidam is too busy to write posts maybe
somebody else can try to stay informed with what is going on and write
instead. I realise many (or most) people here aren't English first
language speakers but I have not had a problem to understand anyone. I
don't think that it is too much of a problem anyway: if we can get a
rough English page then others can edit it and fix errors and then
eventually get translated too.

Sorry to hijack your thread, Quiliro.

--
Morne Alberts

I wrote up a draft bug reporting guidelines document and wanted to throw it up for comment. I would appreciate any feedback.

Bug reporting rules:

Before Reporting a bug:

1 Check upstream to find out if this bug has been reported. Trisquel GNU/Linux is based off Ubuntu and even further upstream Debian. Bugs in either of these distros often make their way down into Trisquel. If the bug is in a specific package also check that program's bug tracker if one is available.

• Check Ubuntu's bug tracker (https://bugs.launchpad.net/ubuntu)
• Check Debian's bug tracker (http://www.debian.org/Bugs/)
• Check the package's bug tracker if one exists

2 Check the bug tracker to make sure this bug has not been reported already. Unfortunately Trisquel does not have the level of manpower other more popular distributions have. Try to avoid duplicate bugs for this reason so that volunteers and developers waste less time on duplicates.

3 Make sure the bug the bug tracker is the appropriate place to report your issue. Not all issues are best suited for the issue tracker. For example, most support issues are best addressed on the forums. Secondly, upstream resources may be better equipped to support your request. For example, The Document Foundation may be better suited to help users with LibreOffice (https://www.libreoffice.org/get-help/) then Trisquel.

• Direct issues to the areas best suited to respond (e.g. forums for support requests)
• Seek upstream documentation/assistance for help with specific packages.

When Reporting a bug:

1 If you were able to find an upstream bug please link to it. Linking a bug to an upstream one helps us track issues better and use less man-power fixing bugs that can be fixed by others. If you were unable to find the bug upstream consider reporting it to the upstream providers as well. Link to upstream bugs to help developers track the issue. If no upstream bug exists previously consider reporting it.

2 Describe the issue clearly. The more information the better. Describe relevant information such as what version of Trisquel you are using, edition (e.g. mini, pro), and software version for any packages. Hardware information may also be useful. As clearly as possible explain the problem and the steps needed to reproduce it. The expected results compared to what actually happens will help volunteers and developers greatly.

3 Select an appropriate priority for the issue. Volunteers and developers use an issue's priority to determine which bugs to fix first and the bugs importance. Marking a non-urgent bug as “critical” hampers these efforts. Some general guidelines include:

• Bugs that violate the GNU Project's Guidelines for Free System Distributions area always “critical”
• A technical “critical” bug is one that causes Trisquel not to function or have a serious flaw.
• A normal bug is one that may affects a specific program or part of Trisquel. It may not be enough to crash the operating system but is an issue. It should be noted that an issue with a specific package may be “critical” in reference to that package but it is “normal” as far as Trisquel is concerned. For example, a critical bug in GIMP (GNU Image Manipulation Program) that causes it to crash is not a critical Trisquel bug. This is because while the bug is critical to that specific program it is not critical to the operating system.
• A minor bug is one that may cause minor annoyances. These may be things like spelling or grammatical errors. They may also be bugs that do not have a major impact on the operating system.

Things to consider when reporting a bug:

1 While not required, if possible report bugs in English. Most Trisquel developers and volunteers speak English. Issues are more likely to be addressed quickly if they are in English. However, submitting a bug in a language other then English is not frowned upon in any way.

I'll give you some answers:

The main problem is the lack of hands, I still do most of the job by myself (maybe the "lack of transparency" mentioned is just me being shy about that). Also it may have been a problem that I traveled way too much this year, I'm sorry if I wasn't very responsive lately.

Since I assumed that the lack of hands may have been caused by the perceived difficulty in stepping up as a developer and start sending patches, I've been working a lot (and with the help of Aklis and others) in making the code accessible and easy to contribute to. We will keep working this way.

Nowadays the core component of the work are the package helpers: http://bzr.trisquel.info/package-helpers/trunk/files

They are *very* simple scripts that modify the source package and compile it for Trisquel. Still, IIRC only one helper was contributed by the community. Regarding how to motivate hackers into sending more patches... well, help make the system better should be enough. Maybe we should do a public "call for hackers" with the help of the FSF and other friend associations around?

Regarding the web site bugs, I'm right now working to make it more wiki-like, in the sense that it should be possible to maintain it without the need of an admin. The blocker for that now is the translation process, which requires some changes in the drupal code we are running on. We are close with this. There have been some volunteers asking to help in developing the site, which I maintain by myself too, but that is just too critical for me to open up easily to volunteers. We need to come up with some middle ground to empower the community in maintaining the site without risks.

Going back to communication issues, one problem I now have is that the forums are way too big for me to monitor, so please those of you who are more involved use the devel list to discuss the important stuff, or link there any important discussion going on. I just stumbled upon this discussion because I'm working to fix the lists-forum sync system.

That would be for development communication, we do need to also improve our community communications, as in writing more news (not only for big events as we do now, but also a sort of project blog, and more participation in social networks). As mentioned, it is not that I prefer to code than to run the community, it is that code alone is already too much work (as the bug list testifies for). I don't like the term "community manager", but it would be nice to have some help in that field.

Regarding how to report bugs, SirGrant as usual provides some good documentation about it, but I'd like to add a rule to the list, maybe to be put first: _include_ _a_ _fix_

This is a small community by all means, and the development part of it is even smaller, so if you find a bug and you are going through the trouble of reporting it, please at least go to the trouble of looking for a solution and attach it. Ideally, write a package helper, but if you at least link to a site discussing how to fix it, it will make the issue much easier to fix.

Also, bear in mind that we are not a big fancy project like Ubuntu (yet), so we cannot afford to debug, patch and compile every possible package (there are over 15000 source packages, and if we nitpick we can find bugs in most of them), and 99% of the problems come from upstream anyway. So don't hesitate to send the bug *directly* upstream if that's the case.

With the exception of freedom related issues, as a general rule we should discard bugs for packages that are not preinstalled in the isos, or even for all that come unmodified from upstream. Sounds sad, but unless we find volunteers or the donations/memberships grow enough to hire some hackers, there is not much we can do about those.

I think quidam's points are all good. I'm just going to emphasise the resources issue and a few ways in which we might find solutions to these issues. I think one of the things Ubuntu has shown works well is the three year release cycle.

While I know a lot of people would abandon Trisquel over the elimination of short term releases I think it is more important to have a usable distribution than a distribution with the latest and "greatest" software.

Right now quidam has about six months to get out each short term release and then that is supported for around a year (Canonical provides security updates for 1 1/2 years after each short term release).

In comparison the long term releases are supported (get security updates from Canonical) for 3 years. If quidam had more time to focus on improving the long term releases we would have a better distribution. quidam could in theory take about a year to release the next distribution after Canonical has released the last Ubuntu long term version.

The main problem that I believe is created with this idea is that of drivers. I think this could be solved quite easily by back porting critical drivers and kernels to the LTS releases.

This would give you the best of both worlds. Stability, security, and support for more recent hardware.

--

What other ideas could solve this problem? Better utilisation of current resources. Volunteers for the dirty jobs. People want to hear from quidam about Trisquel. quidam's time travelling is likely to increase as Trisquel gets more popular. Maybe this problem could be solved by replacing him with a spokesperson. This might be someone whose role is important although whose not necessarily hacking on the distribution to the same degree as quidam. The essential role might be 'architect' Trisquel. This might simply be someone who reviews what other distributions are doing (what components are they using, etc), draws up a design (what components? what features should go into Trisquel 6?), and manages bug reports. Narrowing down the critical components that should go into the next release, making sure we retain critical features, and finding solutions for bug reports for which quidam and/or then implement or filing those bug reports upstream with the solutions. And again. What about managing the web site?

quidam shouldn't be managing the web site. I am guessing here the problem quidam has is he doesn't want to risk down time due to an inexperienced hacker mucking things up.

I think there is a simple solution to security and down time. Lets simply separate concerns. Lets put the bug tracker/forums/wiki and mail into separate virtual instances (assuming the site doesn't get that much peak traffic). I'm guessing here although two instances would probably be enough. There are some good reliable tools which exist and I'm betting we aren't using them.

By being able to pull up copies of different instances you can easily mitigate some of the risks which are created by delegating responsibilities. The mistakes can be more easily recovered from and down time reduced.

Trisquel and ThinkPenguin are both using Drupal for platform management. The systems are very similar so I'm pretty confident this would work well for Trisquel.

I think we have been down for all of maybe two days in a 3-4 year time span and this includes when we transitioned from Drupal 5 to 6. We have redundant daily off site backups of critical pieces (web site) and monthly (roughly) offline copies. All regularly tested and working.

I'll also add if any one here is looking for work we need someone to help with internationalising Ubertcart (primarily). We currently are on Drupal 6.

--

There are also lots of other things which would help increase Trisquel's budget. We need more marketing exposure. Someone with Spanish language skills to help with marketing would be a good start. The more money coming into ThinkPenguin the more we can contribute to free software projects. Right now we are working on some things to help with this although... it's a slow process. Just like with how quidam is overworked the other projects/companies we are working with are too. Creating marketing material, writing press releases, and similar activities should not be done by quidam or other technical individuals. These individuals could be better utilised if there were more people to focus on non-core activities.

>Maybe we should do a public "call for hackers" with the help of the FSF and other friend associations around?

I think this is a great idea. With some planning it could be a smash hit. In English and Spanish. Mentioning the current projects and specific skill sets needed. A very short intro of Trisquel. (but not at the expense of the other free GNU/Linux distros)

We all love you quidam, keep up the good work! And thanks!