Changes

:The way this is normally handled by linux projects is to have two separate tracking system, one for the distribution (http://bugzilla.redhat.com) and one for the project itself (http://bugzilla.gnome.org). Distribution maintainers usually encourage to file bug upstream unless they are distribution specific, and they tend to move them upstream when they are misfiled. This is not very satisfactory because it involves a lot of manual work. In our case it might get a lot worst because we are hopefully going to have *lots* of users not trained to the open source development processes, which will not be able to make a distinction between distribution and upstream project. I'm not sure what's the best solution here. I think clarifying which kind of support and to whom sugarlabs is going to provide will help evaluating our options here. I'm planning to start a thread about, but I'll give you some time to deal with more urgent issues before :) -- Marcopg

:The way this is normally handled by linux projects is to have two separate tracking system, one for the distribution (http://bugzilla.redhat.com) and one for the project itself (http://bugzilla.gnome.org). Distribution maintainers usually encourage to file bug upstream unless they are distribution specific, and they tend to move them upstream when they are misfiled. This is not very satisfactory because it involves a lot of manual work. In our case it might get a lot worst because we are hopefully going to have *lots* of users not trained to the open source development processes, which will not be able to make a distinction between distribution and upstream project. I'm not sure what's the best solution here. I think clarifying which kind of support and to whom Sugar Labs is going to provide will help evaluating our options here. I'm planning to start a thread about, but I'll give you some time to deal with more urgent issues before :) -- Marcopg

===Keywords/Components===

===Keywords/Components===

:This is an excellent starts. I would probably go as far as saying that new features should never be blockers. One problem that I see in many bug systems is that priorities are rarely assigned consistently. Not only because of lack of clarity of the meaning but often just because no one triaged priority. Who is in charge of priority triaging? Reporter, maintainer, release manager? -- marco

:This is an excellent starts. I would probably go as far as saying that new features should never be blockers. One problem that I see in many bug systems is that priorities are rarely assigned consistently. Not only because of lack of clarity of the meaning but often just because no one triaged priority. Who is in charge of priority triaging? Reporter, maintainer, release manager? -- marco

===Verify===

===Verify===