Search found 894 matches

by MichaelC
Sat Feb 21, 2015 2:55 pm
Forum: [3.1/Ascraeus] Merged RFCs
Topic: [RFC] RFC process/management
Replies: 21
Views: 22582

Re: [RFC] RFC process/management

OK, sounds fair enough. So just ditching the RFC altogether? We'll still have RFCs but they won't be required and only used for bigger features In relation to the forum structure, how will it now be structured. I'd propose: - Development -- https://www.phpbb.com/community/ -- General Development Di...
by MichaelC
Mon Feb 16, 2015 10:27 pm
Forum: General Development Discussion
Topic: Git development branches
Replies: 23
Views: 25150

Re: Git development branches

+1
by MichaelC
Sat Feb 07, 2015 2:33 pm
Forum: [3.1/Ascraeus] Merged RFCs
Topic: [RFC] Documentation System and Requirements
Replies: 13
Views: 19497

Re: [RFC] Documentation System and Requirements

I would support having two repositories and instead having a similar system to Symfony where it is required that a PR exists against the docs repo... Which conflicts with your first requirement? You shouldn't need to have to checkout a git repo locally or have to create JIRA issues or know about gi...
by MichaelC
Tue Feb 03, 2015 8:35 am
Forum: [3.x][Archive] RFCs
Topic: Report Spam Users
Replies: 5
Views: 4317

Re: Report Spam Users

-1. A lot of these spam users register but never do anything and letting them sit there has no disadvantage (Unless your concerned by the disk space taken up by a row in a users table?). It's not spam users that are problematic, it's spam posts.
by MichaelC
Tue Jan 27, 2015 6:04 pm
Forum: [3.x] Tickets Discussion
Topic: PHPBB3-11595 - API
Replies: 63
Views: 61393

Re: [RFC] API

brunoais wrote:If you want it to be in the official extensions list, you will have to open source it.
Official extensions are only those developed by the phpBB team, not those written by community members.

https://www.phpbb.com/extensions/official-extensions/
by MichaelC
Mon Jan 26, 2015 9:41 pm
Forum: [3.1/Ascraeus] Merged RFCs
Topic: [RFC] RFC process/management
Replies: 21
Views: 22582

Re: [RFC] RFC process/management

At the moment a feature/improvement goes through these stages: Idea -> RFC -> Ticket -> Pull Request I think Ideas and RFCs are on separate chains: Idea -> Ticket -> Pull Request RFC -> Ticket -> Pull Request An "Idea" doesn't necessarily have an RFC topic in Area51. Also there are a few difference...
by MichaelC
Mon Jan 26, 2015 12:48 am
Forum: [3.x] Tickets Discussion
Topic: [RFC] Extension to fall back to en lang
Replies: 26
Views: 17316

Re: [RFC] Extension to fall back to en lang

ISTs do have extensions and customisations posted on them and not all will have an English language pack, as might those on international 3rd party sites or developed by individuals/organisations for other usage. True but they do have a default lang setup on the forum. Is it possible to add a defau...
by MichaelC
Mon Jan 26, 2015 12:45 am
Forum: [3.1/Ascraeus] Merged RFCs
Topic: [RFC] RFC process/management
Replies: 21
Views: 22582

Re: [RFC] RFC process/management

I agree with Nicofuma's points, however, I personally feel the RFC process on area51 can be scrapped altogether, as it seems most development discussion currently occurs between IRC, JIRA tickets and GitHub PRs. Requiring further discussion here only slows and diffuses the process, which IMO really...
by MichaelC
Thu Jan 22, 2015 8:54 pm
Forum: [3.x] Tickets Discussion
Topic: [RFC] Extension to fall back to en lang
Replies: 26
Views: 17316

Re: [RFC] Extension to fall back to en lang

because extensions are required to have "en". That would make them all English, but at least you won't get any errors. Only by our own (http://www.phpbb.com) customisations database validation policies, not by phpBB itself. ISTs do have extensions and customisations posted on them and not all will ...
by MichaelC
Wed Jan 21, 2015 12:05 pm
Forum: [3.x] Tickets Discussion
Topic: [RFC] Extension to fall back to en lang
Replies: 26
Views: 17316

Re: [RFC] Extension to fall back to en lang

I think there are two other alternatives but I agree something should be done: 1) Fallback to an extension-specific 'default language' defined in composer.json (Accommodates non-english extensions better) or if that is not defined then fall back to en . 2) Look in the extension for language files an...