I propose to introduce votes for all issues, including bug reports, and feature requests.
-- OliverSiemoneit 2006-12-07 10:53:25 Great idea! But this voting system has to be resistent against manipulations..
Well, we can either introduce a lot of red tape, or just trust our users. As I thought of this more as a hint for the developers than as a rule, maybe the latter will do. -- MartinBayer 2006-12-09 19:22:21
Say that to any MoinMoin user interested in the develpoment of this wiki engine (which means anybody with an account in this wiki) 3 votes are granted. He or she may now vote for any bug that he or she wishes to be fixed soon, or to any feature request that he or she wishes to be implemented soon, by assigning it 1, 2, or 3 points until all of the user's votes are used. E.g. you could vote for 3 issues by giving 1 point to each of them, or for 1 issue by giving it all 3 of your points.
You could find at the end of a bug report or feature request page like, say, FeatureRequests/SectionEditing, a line like that:
where the 1st 3 votes are from user A, the 4th from user B, the 6th and the 7th from user C, and so on, but we could also ask users to sign their votes.
That way it would be very much clearer which features are more requested than others, and which bugs do bother more than others, and, hopefully, making MoinMoin fitting more to its users needs.
We could do this very easily with the RatingSystemForMoin.
Absolutely. That is the primary purpose of the RatingSystemForMoin. What we do on our intranet is: We put ideas on separate sub-pages below below the page "Ideas", and we put a rating form on each idea page regarding the subject "interest". (We used to call it "relevance" before, but now we only use "relevance" for bugs/issues.) On the page "Ideas", we put a ranking table like
Ratings(Ideas, interest, */Ideas/*)
Hey and I would be in principle happy with that too and much more happy if we could repackage and publish the code with MM too. Because other people will ilke it too if we do use it here. Zoran it looks quite mature now. Do you like to contribute more like this and may be like to work closer with us and do use a license which does help us to spread your code? -- ReimarBauer 2007-11-09 08:05:32
Theoretically one can re-license Apache licensed code under the GPL3—at least they on gnu.org say that. However, MoinMoin is licensed under "GPL 2 or later", so we would need to step forward (?) to GPL3 with MoinMoin as a whole. I haven't checked whether this would be possible (e.g. code contributions not under "GPL 2 or later", but under "GPL 2" or nothing). LGPL2 ("LGPL 2 or later", to be precise) for all contributions—including the RatingSystemForMoin—would solve the problem. But we already discussed that on ZoranIsailovski's page. -- MartinBayer 2007-11-09 12:36:50
Or: I could re-publish it with a dual Apache/GPL license... -- ZoranIsailovski 2007-11-09 17:44:51
From my experiences with open source projects following a dual license policy, I can't encourage that. Basically, one problem is that code contributions can very easily result in a fork. Dual license is OK if there is only one single copyright holder, because in that case license terms regard only the (re-)distribution of the code, not it's modification. But if you accept third party code contributions—and I guess you would, as otherwise you hadn't chosen a FOSS licensing model—license terms regard also the modification of the code. And any contributor has—as any other user of your code—first to chose under which license terms he is going to modify and re-publish your code. It is completely legal and legitimate to republish the modified code under one of the two original licenses only. This might prevent third party contributions to become part of the core code upstream. And this is not exactly how FOSS software development should work. Even if you re-licensed the code under LGPL "v.2 or later" (which you may, if you are the copyright holder for the work as a whole), there would be a similar problem, as the license explicitly allows to re-publish the code under the terms of the GPL, but once it is GPL, there is no way back to LGPL. IMHO the basic problem is that MoinMoin has no clear policy like we appreciate GPL v.2 licensed contributions.
Hmm, I proposed a dual license because I've already seen dual (and even triple) licensing in FOSS. MoinMoin itself allows for a theoretically unlimited number of licensing alternatives by stating "GPL2 or later", which enables mixing GPL2 and GPL3 (and GPLx in the future). Did this represent a problem for code forks? Did this (quote:) "prevent third party contributions to become part of the core code upstream"? (Nobody can actually tell, I guess, but it doesn't seem so.) So what's the difference to mixing GPL and other FOS, GPL-compatible code (given that Moin's licensing statement explicitly expresses the presence of such code)? Furthermore, I don't see the difference of re-licensing dually licensed Apache/GPL2 code under GPL2 to re-licensing Apache-licensed code under GPL3 (which you suggested above). And last but not least, I think the same "problem" would arise when a package is licensed under GPL3.
Anyway, I feel there is more to it then the arguments presented. (Perhaps I just don't know what exactly happens when something is "re-packaged". Perhaps someone can clarify.)
So, to conclude: It seems you suggest that the only way for the RatingSystemForMoin to be repackaged with Moin is to republish it under GPL2. Did I get you right?
-- ZoranIsailovski 2007-11-10 10:06:55
Maybe this chart clarifies the situation:
Note you must not “mix” GPL2 and GPL3—you can always invoke only one license for copying/modifying one work as a whole. But in some cases you may re-license a work under different license terms—but note the directions of the arrows. Please see also http://www.fsf.org/quick-guide-gplv3-announcement on this topic.
MoinMoin is, more or less, the green field in the middle with the boldface text saying “GPL2 or later”. Thus, it seems most reasonable to license code injections for MoinMoin under “GPL2 or later” or “LGPL2 or later”—but in the latter case the is no possibility for code reflux.
-- MartinBayer 2007-11-10 16:09:50
Messages to me
"Make everything as simple as possible, but not simpler", as somebody said. I know that to usability and ergonomic is not paid the attention they deserve. But as I do care about them, I will continue to contribute usability observations to the development projects of MoinMoin: I believe that enhancing MoinMoin's usability is the best contribution to its development.
-- OliverSiemoneit 2006-12-07 10:53:25 : I totally agree on that. Please do heavily contribute usability and ergonomic aspects in future! I like them! Please do also learn Python to make changes to the code. We don't have thousands of programmers to implement your and user's ideas. Often changes aren't made because of missing time - and we all do work voluntarily on Moin in our leisure time. Please have a look at MoinMoinTodo/Release 1.6.0. We urgently need some changes to the login and userpreferences menus for AccessibleMoin, a Moin version also optimized on usability issues. Maybe you can help on that..
I'm sorry, I won't contribute to MoinMoin's development, including user support, translations, and q/a, any more, at least not as long as it is managed as unprofessionally as it is now. -- MartinBayer 2007-12-27 19:05:50