Re: Project Proposal: GNOME Innovation
On Wed, Oct 7, 2009 at 7:40 PM, Luis Menina wrote: 7. Who would do the work ? As someone already explained, this is not how things work in a community. The ones who decide are not the ones who want, but the ones who actually do the job. I do agree with most of your points, with this caveat: There is a difference between community support and user feedback. Not every user will be part of the community, and many non-community users may have good feedback. The goal should be to involve as many users as possible, while -obtaining good feedback- from those who otherwise will not be involved. This necessitates changing the barrier of entry for non-community members. Obviously the big post whatever you want! system is not be the most effective way to do it. But there must be some way to gain non-technical user feedback that does not involve developer infrastructure. (The dependence upon Bugzillas and Wikis -exclusively and solely- for useful user feedback seems to be a free software phenomenon. Is there no other way of gaining feedback?) I think the discussion is worth pursuing, that's all. It is a gap in the support model of the free software community. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
On Thu, 2009-10-08 at 01:40 +0200, Luis Menina wrote: Wolter Hellmund a écrit : In the following message, I will suggest the creation of a new project entitled GNOME Innovation Hi, I'm going to summarize why I am strongly against that proposal. My reflexion is based on what I saw in Mandriva's equivalent to Ubuntu brainstorm. 1. This creates new work to triage good/bad ideas. To be thoughtful, this needs some people with GNOME good knowledge. It will distract these people from triaging bugs directly in bugzilla, or work on something else. 2. More input doesn't mean more manpower. Even if some ideas are good, this doesn't bring new developers to do the actual job. 3. It lowers the knowledge requirements too much. The consequence is that every single clueless user that thinks he has a good idea leaves a few ideas, and even more clueless users vote for it. People that have the knowledge to differenciate good/doable ideas from the others generally know what a bugzilla is, and fill an enhancement request... 4. Because of (3), most of the ideas I saw on these websites are duplicates of bugzilla bugs or enhancement requests, or are just stuff that already exists, but that the (noob) user didn't find in his desktop. 5. Because of (3) and (4), the signal/noise ratio is very low. 6. The few people that don't know how to use a bugzilla *and* that will propose valuable ideas are most likely going to be pissed off when they'll see it ends up not being implemented, or after a ridiculously long amount of time. Remember we still have bugs in bugzilla that are several years old ! Some of them with patches roting ! Let's fix that before even thinking of the next new *cool* feature the users want. 7. Who would do the work ? As someone already explained, this is not how things work in a community. The ones who decide are not the ones who want, but the ones who actually do the job. If you don't plan to do it yourself, but just rely on other's people work, you've already lost 50% chances to have this ever be done. The Git migration for exemple happened, because some people wanted that to happen, made a survey, and stepped in to do the job. We already lack manpower. Please don't fall on this. It just bring more work with only very small foreseeable gains. Thumbs down. -- Luis Well, you point out some pretty good reasons which make the project look unnecessary. And yes, most of this problems are due to the availability of the project to people who not necessarily put into suggesting ideas much effort or seriousness, hence my recently proposed modification to this project proposal. I suggest that a new component in the GNOME bug database is created that corresponds to the purpose of innovating GNOME. This way, the people who are not serious about suggesting ideas to implement will be avoided at a big percentage; the people who will contribute with GNOME's innovation will be mostly people who care about GNOME and the open source software and consequently know how to move around in a bug filing environment, such as bugzilla. -- Best regards, Wolter Hellmund signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
Wolter Hellmund a écrit : I suggest that a new component in the GNOME bug database is created that corresponds to the purpose of innovating GNOME. This way, the people who are not serious about suggesting ideas to implement will be avoided at a big percentage; the people who will contribute with GNOME's innovation will be mostly people who care about GNOME and the open source software and consequently know how to move around in a bug filing environment, such as bugzilla. If they know how to use bugzilla, they know how to fill an enhancement request on a product. The only thing missing is a place for ideas for new apps, and this IMHO could be done in the wiki. But even that way, I'm not sure it's worth. In the free software community, people that have ideas usually work on them, then show some code, and this in turn brings some contributions if the project is appealing. I have no project in mind that started with someone that just had a good idea and asked to other people to implement it. -- Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
Wolter Hellmund a écrit : In the following message, I will suggest the creation of a new project entitled GNOME Innovation Hi, I'm going to summarize why I am strongly against that proposal. My reflexion is based on what I saw in Mandriva's equivalent to Ubuntu brainstorm. 1. This creates new work to triage good/bad ideas. To be thoughtful, this needs some people with GNOME good knowledge. It will distract these people from triaging bugs directly in bugzilla, or work on something else. 2. More input doesn't mean more manpower. Even if some ideas are good, this doesn't bring new developers to do the actual job. 3. It lowers the knowledge requirements too much. The consequence is that every single clueless user that thinks he has a good idea leaves a few ideas, and even more clueless users vote for it. People that have the knowledge to differenciate good/doable ideas from the others generally know what a bugzilla is, and fill an enhancement request... 4. Because of (3), most of the ideas I saw on these websites are duplicates of bugzilla bugs or enhancement requests, or are just stuff that already exists, but that the (noob) user didn't find in his desktop. 5. Because of (3) and (4), the signal/noise ratio is very low. 6. The few people that don't know how to use a bugzilla *and* that will propose valuable ideas are most likely going to be pissed off when they'll see it ends up not being implemented, or after a ridiculously long amount of time. Remember we still have bugs in bugzilla that are several years old ! Some of them with patches roting ! Let's fix that before even thinking of the next new *cool* feature the users want. 7. Who would do the work ? As someone already explained, this is not how things work in a community. The ones who decide are not the ones who want, but the ones who actually do the job. If you don't plan to do it yourself, but just rely on other's people work, you've already lost 50% chances to have this ever be done. The Git migration for exemple happened, because some people wanted that to happen, made a survey, and stepped in to do the job. We already lack manpower. Please don't fall on this. It just bring more work with only very small foreseeable gains. Thumbs down. -- Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
Andre Klapper a écrit : On a related note: What I agree with is that GNOME is missing a kind of bazaar where people can post their ideas (that do not cover one existing application) and find other people willing to work on it. Wouldn't the wiki be a good place for that ? One could just subscribe to a page that would get the proposals, and see if he wants to contribute. Something under http://live.gnome.org/ResearchAndDevelopment -- Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation - Resolution
Because this proposal has been already widely discussed previously in this mailing list, I request the resolution of it. But before you take a side, I suggest you to read all the comments on this project proposal. I would like to remember you all that this project is not supposed to replace the current bug filing system, but rather to create a new environment for the suggestion of new projects for GNOME. If you feel uncomfortable with implementing IdeaTorrent's Brainstorm System, please provide with alternatives instead of denying the proposal. -- Best regards, Wolter Hellmund signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation - Resolution
Wolter, While I think this is an interesting idea, I don't thing your email below is necessarily the right way to approach this. When you say you below - whom are you referring to? GNOME is a distributed project with hundreds of volunteers all over the world. What infrastructure would be used? How would this be deployed? Managed and maintained? And most importantly, by whom? The sysadmin team already has a number of projects on their plate, and this would need to be prioritized appropriately. You're asking for something to be resolved in a matter of days, and historically that's just not how things work in a community run by volunteers. Our git migration is a great example of something that was talked about for a long time (moving to a DVCS) and finally happened when a handful of volunteers stepped up and made it happen. And before you volunteer yourself, it would be helpful to understand your contributions to the GNOME community. The worst thing that could happen in my opinion is that this implemented and then nothing happens. Those users and developers who contribute ideas and then see no action against them won't be happy. While I believe that it is a great idea to receive feedback and ideas from our users, free software historically has seen innovation by someone who wants to scratch an itch. I don't know of a specific GNOME team or community member who is willing to sign up for maintaining a list of ideas, that may or may not be implemented by a developer. To make a long story short, you may want to re-think your approach to this. Paul On Sat, Oct 3, 2009 at 6:12 PM, Wolter Hellmund wolte...@gmail.com wrote: Because this proposal has been already widely discussed previously in this mailing list, I request the resolution of it. But before you take a side, I suggest you to read all the comments on this project proposal. I would like to remember you all that this project is not supposed to replace the current bug filing system, but rather to create a new environment for the suggestion of new projects for GNOME. If you feel uncomfortable with implementing IdeaTorrent's Brainstorm System, please provide with alternatives instead of denying the proposal. -- Best regards, Wolter Hellmund ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation - Resolution
On Sat, 2009-10-03 at 18:39 -0500, Paul Cutler wrote: Wolter, While I think this is an interesting idea, I don't thing your email below is necessarily the right way to approach this. When you say you below - whom are you referring to? GNOME is a distributed project with hundreds of volunteers all over the world. What infrastructure would be used? How would this be deployed? Managed and maintained? And most importantly, by whom? The sysadmin team already has a number of projects on their plate, and this would need to be prioritized appropriately. You're asking for something to be resolved in a matter of days, and historically that's just not how things work in a community run by volunteers. Our git migration is a great example of something that was talked about for a long time (moving to a DVCS) and finally happened when a handful of volunteers stepped up and made it happen. And before you volunteer yourself, it would be helpful to understand your contributions to the GNOME community. The worst thing that could happen in my opinion is that this implemented and then nothing happens. Those users and developers who contribute ideas and then see no action against them won't be happy. While I believe that it is a great idea to receive feedback and ideas from our users, free software historically has seen innovation by someone who wants to scratch an itch. I don't know of a specific GNOME team or community member who is willing to sign up for maintaining a list of ideas, that may or may not be implemented by a developer. To make a long story short, you may want to re-think your approach to this. Paul I think you have a good point, and for so, I apologize for abruptly trying to push everyone around in the proposal's benefit. I you have a very good point, and it has been discussed and pointed out as one of the weakest points in the project: the lack of manpower. I was just talking to Sandy at IRC and told him about this, but I think its time to let the list know as well. To take advantage of the already established bugzilla system, I think that a new component could be inserted named suggestion, innovation, new, or any short term which would refer to the inexistent. This component would have exactly the same use as the innovation project--it would track all the additions users would like to see in GNOME. Moreover, there would be no need to segregate manpower for the section. Now, in that case, I would consider it appropriate to create as well a mailing list, but that is to be requested at the corresponding department. -- Best regards, Wolter Hellmund signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
Am Donnerstag, den 01.10.2009, 20:20 -0400 schrieb Jud Craft: There is one good reason why this is a good idea: GNOME's support system is too compartmentalized. This shows up all the time in bug reports. People have no idea which component to file against (for particularly tricky situations, even developers have to do some investigation before they arrive at the root cause of the problem). ...so Bugsquad and developers move it to the correct product. Happens sometimes and will always happen. In this context I don't see an argument related to this discussion. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
Hi! Am Freitag, den 02.10.2009, 12:00 +0200 schrieb Andre Klapper: ...so Bugsquad and developers move it to the correct product. Happens sometimes and will always happen. In this context I don't see an argument related to this discussion. I disagree here. Assuming you go to b.g.o and click on File a bug. The next is you are confronted with a big list of possible components. Probably you know the component but for the avarage non-english user it is quite difficult because the component might be translated in his UI. There is no I don't know section on this page that would be forwarded to bugsquad, so the user has the option to file against the wrong component - or he doesn't file at all. In addition and that's maybe what the whole proposal was about, it is hardly possible to file bugs/enhancements against the whole desktop. I think a GNOME Innovation kind of thing would especially be useful for such meta-bugs. Of course, once it is agreed on an innovation, bugs against the individual components should be filed (like for Gnome Goal or the GNOME 3.0 things). Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
On Fri, Oct 2, 2009 at 6:00 AM, Andre Klapper wrote: ...so Bugsquad and developers move it to the correct product. Happens sometimes and will always happen. In this context I don't see an argument related to this discussion. I'm of the opinion voiced by Johannes. An intimidating issue submission process doesn't mean -extra work- for maintainers to organize badly filed bugs -- it means that users don't file bugs in the first place. If I can't figure out what component might be causing a problem I'm seeing, I'll just put off filing the bug. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
On Wed, 2009-09-30 at 11:37 -0700, Sandy Armstrong wrote: On Wed, Sep 30, 2009 at 11:20 AM, Wolter Hellmund wolte...@gmail.com wrote: The project is intended to use a Brainstorm System, which is already provided by IdeaTorrent. It is already implemented in successful projects such as Ubuntu Brainstorm, SourceForge.net and others. Is there any data indicating that Ubuntu Brainstorm works better than filing enhancement bugs? Are there any statistics about how many Ubuntu Brainstorm ideas are actually implemented, and how many are implemented largely due to feedback from Brainstorm? AFAIK, brainstorm.ubuntu.com is used as the base (one of them, the other being bug reports and already existing feature enhancement requests in the bug tracker) for development of new Ubuntu releases. Popular ideas are converted to blueprints (bugs in the GNOME case I guess), then discussed during the UDS (Ubuntu Developer Summit) and assigned for the next cycle. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
There is one good reason why this is a good idea: GNOME's support system is too compartmentalized. This shows up all the time in bug reports. People have no idea which component to file against (for particularly tricky situations, even developers have to do some investigation before they arrive at the root cause of the problem). Detective work is not bad; but a priori detective work, of debugger-caliber, before the user can even flag an end-user issue, is not conducive to enabling user feedback. Under such a system, I could file what seems to me a general issue about keyboard accessibility in GNOME, for example -- without having the slightest clue what part of GNOME is actually responsible for keyboard accessibility (and no, I don't have a clue). The management of such a system (how to link ideas and issues to their components?) is definitely important, but the end-goal would be: easier for the end-user to give feedback on a system he uses, but has not helped build. How do other commercial projects (MSDN - Windows beta testing, Apple, etc) allow user feedback? Do they expect users to discover what component of Explorer is malfunctioning, or what plugin in Windows Media Player they'd like to suggest a change to? Or does the system aid them in automating as much of this homework as possible? On Thu, Oct 1, 2009 at 5:06 AM, Rodrigo Moya rodr...@gnome-db.org wrote: On Wed, 2009-09-30 at 11:37 -0700, Sandy Armstrong wrote: On Wed, Sep 30, 2009 at 11:20 AM, Wolter Hellmund wolte...@gmail.com wrote: The project is intended to use a Brainstorm System, which is already provided by IdeaTorrent. It is already implemented in successful projects such as Ubuntu Brainstorm, SourceForge.net and others. Is there any data indicating that Ubuntu Brainstorm works better than filing enhancement bugs? Are there any statistics about how many Ubuntu Brainstorm ideas are actually implemented, and how many are implemented largely due to feedback from Brainstorm? AFAIK, brainstorm.ubuntu.com is used as the base (one of them, the other being bug reports and already existing feature enhancement requests in the bug tracker) for development of new Ubuntu releases. Popular ideas are converted to blueprints (bugs in the GNOME case I guess), then discussed during the UDS (Ubuntu Developer Summit) and assigned for the next cycle. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
Mr. Craft, I think you've hit one of the most important points in favor of the GNOME Innovation Project, and I thank you for that. It is indeed a quest for the user to file a bug report. The system is not very friendly with people who use their computer for simple tasks such as email, web browsing and music. Now, it is true that people who use linux tend to have more knowledge on computers than the average windows user, or mac user even, but is this a reason for turning down a project which will attempt to create a more comfortable environment for the proposal of ideas and projects? But also remember not to lose track--this project does not attempt to replace bugzilla; the project is intended to route the end-user's creativity to a channel GNOME can access. Now, I understand that tangible limits have to be created in order to decide what should be filed as an enhancement bug, and what should be filed as an idea. - Best regards, Wolter Hellmund On Thu, 2009-10-01 at 20:20 -0400, Jud Craft wrote: There is one good reason why this is a good idea: GNOME's support system is too compartmentalized. This shows up all the time in bug reports. People have no idea which component to file against (for particularly tricky situations, even developers have to do some investigation before they arrive at the root cause of the problem). Detective work is not bad; but a priori detective work, of debugger-caliber, before the user can even flag an end-user issue, is not conducive to enabling user feedback. Under such a system, I could file what seems to me a general issue about keyboard accessibility in GNOME, for example -- without having the slightest clue what part of GNOME is actually responsible for keyboard accessibility (and no, I don't have a clue). The management of such a system (how to link ideas and issues to their components?) is definitely important, but the end-goal would be: easier for the end-user to give feedback on a system he uses, but has not helped build. How do other commercial projects (MSDN - Windows beta testing, Apple, etc) allow user feedback? Do they expect users to discover what component of Explorer is malfunctioning, or what plugin in Windows Media Player they'd like to suggest a change to? Or does the system aid them in automating as much of this homework as possible? On Thu, Oct 1, 2009 at 5:06 AM, Rodrigo Moya rodr...@gnome-db.org wrote: On Wed, 2009-09-30 at 11:37 -0700, Sandy Armstrong wrote: On Wed, Sep 30, 2009 at 11:20 AM, Wolter Hellmund wolte...@gmail.com wrote: The project is intended to use a Brainstorm System, which is already provided by IdeaTorrent. It is already implemented in successful projects such as Ubuntu Brainstorm, SourceForge.net and others. Is there any data indicating that Ubuntu Brainstorm works better than filing enhancement bugs? Are there any statistics about how many Ubuntu Brainstorm ideas are actually implemented, and how many are implemented largely due to feedback from Brainstorm? AFAIK, brainstorm.ubuntu.com is used as the base (one of them, the other being bug reports and already existing feature enhancement requests in the bug tracker) for development of new Ubuntu releases. Popular ideas are converted to blueprints (bugs in the GNOME case I guess), then discussed during the UDS (Ubuntu Developer Summit) and assigned for the next cycle. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
On Wed, Sep 30, 2009 at 11:20 AM, Wolter Hellmund wolte...@gmail.com wrote: The project is intended to use a Brainstorm System, which is already provided by IdeaTorrent. It is already implemented in successful projects such as Ubuntu Brainstorm, SourceForge.net and others. Is there any data indicating that Ubuntu Brainstorm works better than filing enhancement bugs? Are there any statistics about how many Ubuntu Brainstorm ideas are actually implemented, and how many are implemented largely due to feedback from Brainstorm? I would hate to implement a system like this that gave users a false impression of being able to vote features into GNOME, so I think hard data showing that's not what would happen is important. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
On Wed, 2009-09-30 at 12:20 -0600, Wolter Hellmund wrote: Greetings, I am a new member of the GNOME contributors community. In the following message, I will suggest the creation of a new project entitled GNOME Innovation in HTML format for easier comprehension. Please use ASCII. Some people may use even CLI newsgroup clients (via gmane). (...) Ok. The only feature different then bugzilla is vote down AFAIU. Moderation is similar to marking NEW and vote up to adding to CC. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
On Wed, 2009-09-30 at 20:40 +0200, Maciej Piechotka wrote: On Wed, 2009-09-30 at 12:20 -0600, Wolter Hellmund wrote: Greetings, I am a new member of the GNOME contributors community. In the following message, I will suggest the creation of a new project entitled GNOME Innovation in HTML format for easier comprehension. Please use ASCII. Some people may use even CLI newsgroup clients (via gmane). (...) Ok. The only feature different then bugzilla is vote down AFAIU. Moderation is similar to marking NEW and vote up to adding to CC. Note that bugzilla does have a voting feature. We explicitly do not enable it. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
On Wed, 2009-09-30 at 13:57 -0500, Shaun McCance wrote: On Wed, 2009-09-30 at 20:40 +0200, Maciej Piechotka wrote: On Wed, 2009-09-30 at 12:20 -0600, Wolter Hellmund wrote: Greetings, I am a new member of the GNOME contributors community. In the following message, I will suggest the creation of a new project entitled GNOME Innovation in HTML format for easier comprehension. Please use ASCII. Some people may use even CLI newsgroup clients (via gmane). (...) Ok. The only feature different then bugzilla is vote down AFAIU. Moderation is similar to marking NEW and vote up to adding to CC. Note that bugzilla does have a voting feature. We explicitly do not enable it. No. You explicitly changed it to CC system ;) - if something is worth it user agree to get spammed by updates ;) Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
Well, I am really sorry for using HTML. I thought it would be liked. Well, there is no data indicating that Ubuntu Brainstorm works better than filing enhancement bugs, for that takes the elaboration of an investigation I am not prepared to launch. As far as I know, there is no user-accessible numeric record with the information you request in your second question. Most of the implemented ideas have very good solution ratings, yes. However, it is always subject to the developer's time and their will of implementing the idea. - Best regards, Wolter Hellmund On Wed, 2009-09-30 at 11:37 -0700, Sandy Armstrong wrote: On Wed, Sep 30, 2009 at 11:20 AM, Wolter Hellmund wolte...@gmail.com wrote: The project is intended to use a Brainstorm System, which is already provided by IdeaTorrent. It is already implemented in successful projects such as Ubuntu Brainstorm, SourceForge.net and others. Is there any data indicating that Ubuntu Brainstorm works better than filing enhancement bugs? Are there any statistics about how many Ubuntu Brainstorm ideas are actually implemented, and how many are implemented largely due to feedback from Brainstorm? I would hate to implement a system like this that gave users a false impression of being able to vote features into GNOME, so I think hard data showing that's not what would happen is important. Sandy signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
Wolter: I think your graphic flowchart is a good start. However, a lot of GNOME modules do not really have active maintainers. To date, I think the community has dealt with that problem in an ad hoc manner. However, if we are going to formalize how such a process works, then I think i would be of value to make it more clear how modules without active maintainers are maintained. Maciej: Ok. The only feature different then bugzilla is vote down AFAIU. Moderation is similar to marking NEW and vote up to adding to CC. I think one main benefit to the innovation idea is that it creates an archive where people can, hopefully, go to find out the discussion behind particular design choices, and what issues were considered. This can be helpful reference, for example, when trying to make changes to that code later or replacing it with something new. Since much of this discussion has already happened on mailing lists, it would be especially useful if the innovation tool made it easy to reference such past threads. It would be neat if you could go to some website and quickly find links to particular design discussions that happened in the past, whether on mailing list or captured directly in the innovation tool. This sort of process is also similar to the OpenSolaris ARC (Architecture Review Committee), where you have a process to help make architectural decisions. http://www.opensolaris.org/os/community/arc/ In this process, the focus is on a project's interfaces moreso than the internal, or private, architecture of a given module. The focus is more to ensure that modules integrate well together on the system. For a project like GNOME, there might be more value in studying and documenting the internal architecture of some modules, though. The ARC process is probably not the right fit for the GNOME community, but I'd encourage people to read some about how the process works and cherry pick any good ideas that might apply. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
On Wed, 2009-09-30 at 13:11 -0600, Wolter Hellmund wrote: Well, I am really sorry for using HTML. I thought it would be liked. Ups. Sorry if I was too mean. I'm just somehow old-style person who still uses USENET ;) AFAIK HTML in email is not liked very much among at least some old-style people. Probably because it makes processing harder etc. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
Am Mittwoch, den 30.09.2009, 12:20 -0600 schrieb Wolter Hellmund: In the following message, I will suggest the creation of a new project entitled GNOME Innovation in HTML format for easier comprehension. On a related note: What I agree with is that GNOME is missing a kind of bazaar where people can post their ideas (that do not cover one existing application) and find other people willing to work on it. I liked the piece of paper on the GNOME wall at the last FOSDEM conference where people could enter their project name contact info and state that they search for more developers and input. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
When we were having discussions on version control systems, one of the ideas that I had thrown out for a git/bzr over a centralized version control was that fact that we could branch all of GNOME on an experimental branch and create a bazaar for ideas. A lot of times in this mailing list we get bogged down over issues of stability and performance as we are now a mature software project and so we have a lot of restrictions on how we introduce features into our eco-system. But what attracts people is the ability to innovate and be able to break the rules as it is and be able to express ideas whether they are crack or not. We would also be able to attract younger talent and a new generation of code contributors/maintainers. Something worth thinking about and it would be fairly easy to start something like that, although there is a lot of demons in the details if you want the branch to actually be useful over time (eg controlled chaos, not chaos) sri On Wed, Sep 30, 2009 at 12:29 PM, Wolter Hellmund wolte...@gmail.comwrote: Well, thanks a lot Brian for the good prospect. You did mention yourself a couple of arguments I forgot in my last reply. For those of you who misunderstood the idea of Innovation, and why it is not the same thing as bugzilla but with votes, here is my explanation: The idea behind Innovation is not to solve bugs for existing projects (it can work that way, but that is not the idea). It is precisely for innovation--for suggesting things never seen before. It is true: manpower is a highly important factor which might conform a weak point for this Innovation Environment. - Best regards, Wolter Hellmund On Wed, 2009-09-30 at 14:15 -0500, Brian Cameron wrote: Wolter: I think your graphic flowchart is a good start. However, a lot of GNOME modules do not really have active maintainers. To date, I think the community has dealt with that problem in an ad hoc manner. However, if we are going to formalize how such a process works, then I think i would be of value to make it more clear how modules without active maintainers are maintained. Maciej: Ok. The only feature different then bugzilla is vote down AFAIU. Moderation is similar to marking NEW and vote up to adding to CC. I think one main benefit to the innovation idea is that it creates an archive where people can, hopefully, go to find out the discussion behind particular design choices, and what issues were considered. This can be helpful reference, for example, when trying to make changes to that code later or replacing it with something new. Since much of this discussion has already happened on mailing lists, it would be especially useful if the innovation tool made it easy to reference such past threads. It would be neat if you could go to some website and quickly find links to particular design discussions that happened in the past, whether on mailing list or captured directly in the innovation tool. This sort of process is also similar to the OpenSolaris ARC (Architecture Review Committee), where you have a process to help make architectural decisions. http://www.opensolaris.org/os/community/arc/ In this process, the focus is on a project's interfaces moreso than the internal, or private, architecture of a given module. The focus is more to ensure that modules integrate well together on the system. For a project like GNOME, there might be more value in studying and documenting the internal architecture of some modules, though. The ARC process is probably not the right fit for the GNOME community, but I'd encourage people to read some about how the process works and cherry pick any good ideas that might apply. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
