# 5.4 moving forward - Thread: https://externals.io/message/52812 - Original archive: https://news-web.php.net/php.internals/52812 - Started by Stas Malyshev on 2011-06-02T20:24:25+00:00 - Messages: 60 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/52812.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #52812 — Stas Malyshev — 2011-06-02T20:24:25+00:00 URL: https://externals.io/message/52812#52812 Hi! We're having pretty lively discussion on the list, twitter and other places, but let's not forget the big goal of 5.4 :) 1. First of all, the official business. Any objections to the RMs for 5.4 being: Stas Malyshev (stas) David Soria Parra (dsp) If not, we'll be the 5.4 RM team. 2. Candidates for 5.4: please review this list: https://wiki.php.net/todo/php54 I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Some of the items are already being discussed, but I'll prepare some kind of official "ballot" and send to the list soon so we'd have common point. I think it makes sense to have the following limits of the features: a. It should be either obvious how to do it (example: adding `E_STRICT` to E_ALL), or have full design & working patch w/tests or somebody has to commit to doing it within roughly a month term. b. I think we should leave out any big things now, e.g.: annotations - sorry, I know there are many people supporting it, but right now it doesn't seem to be a consensus on how to do it, so I'd rather target 5.5 for it, which if we can make this release go smoothly won't have to be too far out. 3. I'd like to create first alpha sometime next week, if somebody has anything that's not in and wants it in please talk to me. This alpha should in no way be seen as anything stable or final, but rather as a first step on a road to 5.4. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #52814 — Pierre Joye — 2011-06-02T21:17:06+00:00 URL: https://externals.io/message/52812#52814 · In reply to: #52812 hi, I have no objection as long as the RFC for the release process is adopted before we do any 5.4 releases, as stated earlier, this is the only way to put ourself on the safe side. Cheers, > Hi! > > We're having pretty lively discussion on the list, twitter and other places, > but let's not forget the big goal of 5.4 :) > > 1. First of all, the official business. Any objections to the RMs for 5.4 > being: > Stas Malyshev (stas) > David Soria Parra (dsp) > > If not, we'll be the 5.4 RM team. > > 2. Candidates for 5.4: please review this list: > https://wiki.php.net/todo/php54 > > I'd like to set up a vote for the undecided TODO features on wiki.php.net, > anybody could help me with setting up the voting module there if there's > such thing on the wiki? Or set me up with the access to wiki machine and > I'll install it :) > > Some of the items are already being discussed, but I'll prepare some kind of > official "ballot" and send to the list soon so we'd have common point. > > I think it makes sense to have the following limits of the features: > a. It should be either obvious how to do it (example: adding `E_STRICT` to > E_ALL), or have full design & working patch w/tests or somebody has to > commit to doing it within roughly a month term. > > b. I think we should leave out any big things now, e.g.: annotations - > sorry, I know there are many people supporting it, but right now it doesn't > seem to be a consensus on how to do it, so I'd rather target 5.5 for it, > which if we can make this release go smoothly won't have to be too far out. > > 3. I'd like to create first alpha sometime next week, if somebody has > anything that's not in and wants it in please talk to me. This alpha should > in no way be seen as anything stable or final, but rather as a first step on > a road to 5.4. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52816 — Ilia Alshanetsky — 2011-06-02T21:24:22+00:00 URL: https://externals.io/message/52812#52816 · In reply to: #52812 Sounds fine to me. > Hi! > > We're having pretty lively discussion on the list, twitter and other places, > but let's not forget the big goal of 5.4 :) > > 1. First of all, the official business. Any objections to the RMs for 5.4 > being: > Stas Malyshev (stas) > David Soria Parra (dsp) > > If not, we'll be the 5.4 RM team. > > 2. Candidates for 5.4: please review this list: > https://wiki.php.net/todo/php54 > > I'd like to set up a vote for the undecided TODO features on wiki.php.net, > anybody could help me with setting up the voting module there if there's > such thing on the wiki? Or set me up with the access to wiki machine and > I'll install it :) > > Some of the items are already being discussed, but I'll prepare some kind of > official "ballot" and send to the list soon so we'd have common point. > > I think it makes sense to have the following limits of the features: > a. It should be either obvious how to do it (example: adding `E_STRICT` to > E_ALL), or have full design & working patch w/tests or somebody has to > commit to doing it within roughly a month term. > > b. I think we should leave out any big things now, e.g.: annotations - > sorry, I know there are many people supporting it, but right now it doesn't > seem to be a consensus on how to do it, so I'd rather target 5.5 for it, > which if we can make this release go smoothly won't have to be too far out. > > 3. I'd like to create first alpha sometime next week, if somebody has > anything that's not in and wants it in please talk to me. This alpha should > in no way be seen as anything stable or final, but rather as a first step on > a road to 5.4. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #52817 — Hannes Magnusson — 2011-06-02T21:29:17+00:00 URL: https://externals.io/message/52812#52817 · In reply to: #52812 > I'd like to set up a vote for the undecided TODO features on wiki.php.net, > anybody could help me with setting up the voting module there if there's > such thing on the wiki? Or set me up with the access to wiki machine and > I'll install it :) You are in general much more likely to get serious reply on this sort of things on the.. mailinglists dedicated for it (php-webmaster@ / systems@). There is just way to much trolling going on on this list for us to be able to read all posts. The wiki code is in svn, so you should be able to commit whatever plugin you need. If you need access to the actual box, ask the technical contact listed on https://wiki.php.net/systems/rl, or systems@ for any other questions. > Some of the items are already being discussed, but I'll prepare some kind of > official "ballot" and send to the list soon so we'd have common point. There are still leftovers from the scalar type hint in svn, check zend_do_receive_arg() and zend_do_perform_implementation_check() for example. Please verify you reverted it properly, as these half-reverting is causing segfaults whereas syntax error would be expected. -Hannes --- ## #52837 — Derick Rethans — 2011-06-03T07:45:37+00:00 URL: https://externals.io/message/52812#52837 · In reply to: #52812 > I'd like to set up a vote for the undecided TODO features on > wiki.php.net, anybody could help me with setting up the voting module > there if there's such thing on the wiki? Or set me up with the access > to wiki machine and I'll install it :) Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all "votes" are showing up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). Derick --- ## #52842 — Alexey Shein — 2011-06-03T08:01:00+00:00 URL: https://externals.io/message/52812#52842 · In reply to: #52837 2011/6/3 Derick Rethans : > > > > […] > > Voting on the wiki? Yuck. If you want participation, do it here on the > mailinglist and store the record in the wiki. If all "votes" are showing > up just in the wiki then there is no exposure on the list and things are > easy to miss (especially with the huge amount of noise that's already on > the list). > Why not just to separate voting from participation? I doubt there is somebody that counts all these +1 in the list and tracks progress. I suggest keep voting only in wiki and discussions in ML. Don't have consice opinion yet? Participate ML. Got opinion? Go and vote in the wiki, no need to +1/-1 in the list, it's already too much noise here. > Derick > > -- > > > > -- Regards, Shein Alexey --- ## #52843 — Stas Malyshev — 2011-06-03T08:03:00+00:00 URL: https://externals.io/message/52812#52843 · In reply to: #52837 Hi! > Voting on the wiki? Yuck. If you want participation, do it here on the > mailinglist and store the record in the wiki. If all "votes" are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. > up just in the wiki then there is no exposure on the list and things are > easy to miss (especially with the huge amount of noise that's already on > the list). There will be exposure to the list, with list of topics and explanations. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #52844 — Michael Shadle — 2011-06-03T08:10:30+00:00 URL: https://externals.io/message/52812#52844 · In reply to: #52843 Why doesnt voting happen using a poll/voting engine. Written in (gasp) PHP! (although soon PJSON) > Hi! > > > […] > > Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. > > > […] > > There will be exposure to the list, with list of topics and explanations. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #52845 — Pierre Joye — 2011-06-03T08:16:22+00:00 URL: https://externals.io/message/52812#52845 · In reply to: #52837 hi Derick, > > > > […] > > Voting on the wiki? Yuck. If you want participation, do it here on the > mailinglist and store the record in the wiki. If all "votes" are showing > up just in the wiki then there is no exposure on the list and things are > easy to miss (especially with the huge amount of noise that's already on > the list). Please re consider your opinion like "noises on the list" and other similar statements, thanks. As of the votes in the wiki, it is perfectly fine and valid, easy to manage and open. Much more easier than counting random votes in the ML, especially when discussions are split in many threads. The discussions and related activities do happen on the list and that's a good thing. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52846 — Derick Rethans — 2011-06-03T08:22:36+00:00 URL: https://externals.io/message/52812#52846 · In reply to: #52843 > > […] > > Voting on ML is messy and means somebody needs to read every message on the > list and look for votes, however long, tedious and offtopic the discussion > gets. Voting with, well, voting application is clean, automatic and efficient. > I don't understand why we should use medium that is unfit for the purpose > instead of using applications specifically designed for doing what we try to > do. Yes, it's messy on ML. My points where: - a call to vote is easily drowned out on the ML with all the noise - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). And IMO, those two things should be sorted out before we "decide" to do votes by editting some page on some wiki. Derick --- ## #52847 — Pierre Joye — 2011-06-03T08:27:48+00:00 URL: https://externals.io/message/52812#52847 · In reply to: #52846 > > > > […] > > Yes, it's messy on ML. My points where: > - a call to vote is easily drowned out on the ML with all the noise > - editting votes on a wiki can too easily be manipulated (I could just >  change your votes, and there would be no trail). There is a log and we know who did edit what. Basic trust is required anyway and if such tricks happen, really, I do not know what to think about the person doing them (well I do, but that's not the place to say it). A plugin will be installed to ease the process, login, vote. You won't be able to add/edit other votes. About when a vote happens and how to inform the devs, I do not see other solutions than getting the devs to read the discussions on the MLs. If some can't stand the heat, then we can't do much for them anyway, Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52848 — Drak — 2011-06-03T08:32:17+00:00 URL: https://externals.io/message/52812#52848 · In reply to: #52847 Have you guys considered doodle.com? I think you are all stressing way too much over the voting process. When a vote is closed you can then transfer the decision to the RFC. Drak > > > […] > showing > > […] > the > > […] > discussion > > […] > efficient. > > […] > purpose > > […] > try to > > […] > > There is a log and we know who did edit what. Basic trust is required > anyway and if such tricks happen, really, I do not know what to think > about the person doing them (well I do, but that's not the place to > say it). > > A plugin will be installed to ease the process, login, vote. You won't > be able to add/edit other votes. > > About when a vote happens and how to inform the devs, I do not see > other solutions than getting the devs to read the discussions on the > MLs. If some can't stand the heat, then we can't do much for them > anyway, > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52849 — Stas Malyshev — 2011-06-03T08:35:30+00:00 URL: https://externals.io/message/52812#52849 · In reply to: #52846 Hi! > - a call to vote is easily drowned out on the ML with all the noise I read the same ML as you do :) Using threaded email client it is very easy to separate new threads and see calls for votes. Also, voting on ML does not solve the "drowning out" problem, it makes it worse as about 80% of the people in given vote in a given moment can't say what they are/supposed to be voting for, is discussion still ongoing and what's the consensus, if any. > - editting votes on a wiki can too easily be manipulated (I could just > change your votes, and there would be no trail). Votes are public, if you see somebody edited it you'd notice. As editing could be done only by admins (if I understand correctly, same guys having root on pretty much all PHP infrastructure) if a plugin is used (see below) I don't think it's a big concern. > And IMO, those two things should be sorted out before we "decide" to do > votes by editting some page on some wiki. docuwiki has voting plugins for that purpose, editing some page is not the only way. For example: http://www.dokuwiki.org/plugin:doodle2 -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #52850 — Derick Rethans — 2011-06-03T08:42:27+00:00 URL: https://externals.io/message/52812#52850 · In reply to: #52849 > > […] > > I read the same ML as you do :) Using threaded email client it is very > easy to separate new threads and see calls for votes. That is subjective. And even with a threaded client, if there are 80+ new messages then the call for vote is drowned out. *Requiring* something like [VOTE] in the subject helps, as then you can set-up a filter. And if it's a requirement, every call without [VOTE] in the subject is invalid. (Easy to fix if somebody forgot it as well). It would expose this kind of thing. > Also, voting on ML does not solve the "drowning out" problem, it makes > it worse as about 80% of the people in given vote in a given moment > can't say what they are/supposed to be voting for, is discussion still > ongoing and what's the consensus, if any. I didn't disagree with this. > > […] > > Votes are public, if you see somebody edited it you'd notice. As > editing could be done only by admins (if I understand correctly, same > guys having root on pretty much all PHP infrastructure) if a plugin is > used (see below) I don't think it's a big concern. > > > […] > > docuwiki has voting plugins for that purpose, editing some page is not the > only way. For example: http://www.dokuwiki.org/plugin:doodle2 There is no plugin used for it yet, and that's my problem with it. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #52856 — Ronald Chmara — 2011-06-03T11:03:58+00:00 URL: https://externals.io/message/52812#52856 · In reply to: #52850 > > > […] > That is subjective. And even with a threaded client, if there are 80+ > new messages then the call for vote is drowned out. We have *at least*a million PHP users. Maybe a billion now. (For those who were educated in the United States, a billion is a thousand times a million). If someone can't handle as mere 80 votes, well... maybe that's the problem. > *Requiring* > something like [VOTE] in the subject helps, as then you can set-up a > filter. And if it's a requirement, every call without [VOTE] in the > subject is invalid. (Easy to fix if somebody forgot it as well). It > would expose this kind of thing. Read. Every. Message... or figure out another way. If you do not have the time to do so, maybe it's time to "check out" of a project. I read 900+ emails a day. I do not think others are incapable of this. > > […] > I didn't disagree with this. All voting is messy. As are opinions. > > […] My problem is with the idea, and practice, of astroturfing, and other vote stacking methods. Moving from a mailinglist to a wiki does not change this problem, it just provides another media to play with.... without addressing the issue. I've been with the PHP project, off and on, for at least ten years now (hell, I have had "core commit" for ages, but rasmus, stas, zeev, andi wouldn't even recognize my face). and I've seen... interesting.... things over the years. It's not a democracy, it's a meritocracy. Votes don't count for much, other than expressing interest. If you want to change core, you have to send patches. Good patches. Working patches. Patches that don't fuck up testers, We can argue for years about whether or not code *should* be written, and take useless votes (IMHO) about it, or we can write the code. What we should not do... is whine about others not writing the code for us. Putting the whine on a mailing list, or a wiki, or twitter, or IRC, or won't change that. -Ronabop --- ## #52864 — Martin Scotta — 2011-06-03T15:25:36+00:00 URL: https://externals.io/message/52812#52864 · In reply to: #52845 Martin Scotta > hi Derick, > > > > […] > > Please re consider your opinion like "noises on the list" and other > similar statements, thanks. > > As of the votes in the wiki, it is perfectly fine and valid, easy to > manage and open. Much more easier than counting random votes in the > ML, especially when discussions are split in many threads. The > discussions and related activities do happen on the list and that's a > good thing. > Yes, but only who has wiki karma are allowed to vote. > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52865 — dukeofgaming — 2011-06-03T15:34:57+00:00 URL: https://externals.io/message/52812#52865 · In reply to: #52864 How about a separate email topic dedicated to voting?, that would reduce the signal to noise ratio for votes (and increase it for opinions). Regards, David On Fri, Jun 3, 2011 at 10:25 AM, Martin Scotta wrote: > Martin Scotta > > > > > > […] > showing > > […] > are > > […] > on > > […] > > Yes, but only who has wiki karma are allowed to vote. > > > > […] --- ## #52878 — Stas Malyshev — 2011-06-04T03:46:35+00:00 URL: https://externals.io/message/52812#52878 · In reply to: #52850 Hi! > That is subjective. And even with a threaded client, if there are 80+ > new messages then the call for vote is drowned out. *Requiring* There was never 80+ new messages on different topics on the list. There are 3-4 topics max, if you not count commit messages. Each of them can contain dozens of messages, but those can be easily grouped. > something like [VOTE] in the subject helps, as then you can set-up a [VOTE] is a good idea, let's make it [VOTE]. > There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #52881 — Pierre Joye — 2011-06-04T10:07:34+00:00 URL: https://externals.io/message/52812#52881 · In reply to: #52878 > [VOTE] is a good idea, let's make it [VOTE]. > > > […] > > Well, votes aren't announced yet either :) I'll try to get it set up ASAP > and see how it works, before announcing the vote. It looks good in > description at least. Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52884 — Philip Olson — 2011-06-04T13:29:41+00:00 URL: https://externals.io/message/52812#52884 · In reply to: #52881 > > > > […] > > Please keep them in the wiki as we planed to do. THere are plugins and > it is very easy to manage, allows per section voting etc. I'm hopeful people will continue to understand the RFC definition: - RFC: Request For Comments And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached. Also, people should be given a reasonable opportunity to offer an alternative RFC. Regards, Philip --- ## #52887 — John Crenshaw — 2011-06-04T15:09:48+00:00 URL: https://externals.io/message/52812#52887 · In reply to: #52884 Speaking generally, consensus is a dangerous and impossible standard. Few things can cripple progress like waiting for consensus. Voting may be one good way to move things forward without deadlocking forever. I agree though that without clear rules for how the process should work, voting is also chaotic. (Who can call for a vote? How? When is it final? Who can vote? How do they vote? How much is each vote worth? Is a simple majority or super majority needed?) John Crenshaw Priacta, Inc. -----Original Message----- From: Philip Olson [mailto:philip@roshambo.org] Sent: Saturday, June 04, 2011 9:30 AM To: Pierre Joye Cc: Stas Malyshev; Derick Rethans; PHP Internals Subject: Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward) > > > > […] > > Please keep them in the wiki as we planed to do. THere are plugins and > it is very easy to manage, allows per section voting etc. I'm hopeful people will continue to understand the RFC definition: - RFC: Request For Comments And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached. Also, people should be given a reasonable opportunity to offer an alternative RFC. Regards, Philip --- ## #52889 — Pierre Joye — 2011-06-04T17:23:26+00:00 URL: https://externals.io/message/52812#52889 · In reply to: #52884 hi Philip, >  - RFC: Request For Comments Thanks for the reminder. But RFC got approved at some point as well. See the numerous W3C RFCs for some known examples. > And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. What got messy? That instead of simply rejecting the RFC instead of constantly adding new ideas to the stack. It is a perfectly valid flow to block a RFC because it is considered as not well designed, not desired or simple not fully compliant. It happened many times in php in the past and in other projects as well. > Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached. I'm sorry to not be powerful enough to achieve my ultimate goal, have the most open processes and decissions in the OSS world within PHP. That is, to include the communities in the decision processes and not only to propose things. Now you can keep arguing that voting is pointless, unfair, that consensus can be reached easily, etc. etc. What we see is a total different picture which is more related to dictatorial decisions or puchists. None of these ways are good. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52890 — Stas Malyshev — 2011-06-04T17:58:36+00:00 URL: https://externals.io/message/52812#52890 · In reply to: #52881 Hi! > Please keep them in the wiki as we planed to do. THere are plugins and > it is very easy to manage, allows per section voting etc. I've installed voting plugin, see description here: http://www.dokuwiki.org/plugin:doodle2 and example how it looks here at the end (login required to vote): https://wiki.php.net/playground/playground I think it'd work. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #52891 — Pierre Joye — 2011-06-04T18:04:39+00:00 URL: https://externals.io/message/52812#52891 · In reply to: #52890 right, that's the one I was willing to install as well, great that you did it! Thanks :) > Hi! > > > […] > > I've installed voting plugin, see description here: > > http://www.dokuwiki.org/plugin:doodle2 > > and example how it looks here at the end (login required to vote): > > https://wiki.php.net/playground/playground > > I think it'd work. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52892 — Hannes Magnusson — 2011-06-04T18:25:11+00:00 URL: https://externals.io/message/52812#52892 · In reply to: #52890 > Hi! > > > […] > > I've installed voting plugin, see description here: > > http://www.dokuwiki.org/plugin:doodle2 > > and example how it looks here at the end (login required to vote): > > https://wiki.php.net/playground/playground > > I think it'd work. How does it work? Do you need write permission to the page it is located on, or is it enough to have login? How do you differentiate between 'core' and 'community' voting? (or is that maybe not needed?) -Hannes --- Next page: https://externals.io/message/52812.md?page=2