On 02/08/2015 20:10, Marcio Almada wrote:
As you pointed github issues, it's worth noting that Rust internals already use github to manage RFCs: https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AT-lang
That's interesting. Do you have a link to any documentation on the process they use? For instance, how does the RFC gain final approval / rejection?
For general discussion and pre RFCs they are using their own discuss instance. You can login with github in 2 clicks or simply lurk and search through the threads:https://internals.rust-lang.org/
Right, so just as I mentioned phpBB earlier, they've set up a discussion forum. It's not a piece of software I'm familiar with, so I can't speak for its pros and cons vs a mailing list (apart from a personal dislike of Infinite Scroll in place of pagination).
On 02/08/2015 20:17, Dor Tchizik wrote:
This is what I think. The best way to deter the community from making contributions is to make it hard to contribute.
Agreed.
My C/C++ savvy buddy told me about an awesome feature he wants to see in iojs, I can tell him to go on GitHub and raise the issue, discussion took place, and he'd submitted a pull request, which subsequently got accepted. The entire process took two days, mainly due to timezone differences.
You can do this with PHP as well - Pull Requests are accepted on GitHub. I gather there is a bit of an issue with back log right now, and suggestions for improving that are welcome.
Everyone were helpful and to the point.
That's good to hear. Completely unrelated to the tools used, however.
Now, I get that the RFC process in PHP is different, but why is it that to even GET on the mailing list one needs to go through seven hells,
I remember it being pretty trivial - enter my e-mail address, verify my e-mail address, skim-read the etiquette doc, start discussing.
only to be in the discussion (often completely irrelevant to what he's trying to do) for several weeks or months
If you're not interested in a particular discussion thread, don't read and respond to it. Even GMail's subject-based "conversations" (which, you may have gathered, I dislike) are perfectly adequate for that purpose.
On other other hand, if you want to become part of any community, it pays to get a feel for what's going on and the general mood. Again, the need for this is largely unrelated to the tools used; and if everything was fractured into a thousand Issue threads, this would probably be harder, not easier.
, to get Karma, and only then may he submit an RFC? Why can't someone just open an issue, and have an RFC up and ready the next day (or even the next week)?
OK, so now we're talking about something completely different again - not bugs, or patches for minor enhancements, but major changes to the language or core functionality. Yes, there is a somewhat bureaucratic process for these, in part because the lack of nominated project leaders means some way of achieving and measuring consensus is required.
The need for wiki karma is sort of annoying, although it's given out fairly readily from what I can see. It's a fancy word for "you need a login to this tool, because we don't want it filling up with complete spam", but maybe it could be stream-lined further. Nothing to do with whether we use a mailing list as the main forum though.
If you want to improve the RFC process itself, that's a whole different topic. That might mean more collaboration on the wiki itself, a better process for summarising points raised so far, etc. If anything, RFCs need a *less* conversation-like interface, not more, because currently the discsussions tend to get rather repetitive on contentious issues.
It's this exact approach that pushes valuable community members away, several members of internals whom I value had left internals for various reasons, mostly regarding the atmosphere in the mailing list.
An oft-acknowledged fact.
And the way you improve the atmosphere is to get more people, more eyes, more opinions.
Is it? I'm really not sure - if the problem is too many conflicting opinions, then adding more people into the mix just makes things worse; if the problem is too few people who really know and love the core, then getting more contributors really actively involved would help...
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
