Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100023 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46775 invoked from network); 23 Jul 2017 22:04:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jul 2017 22:04:03 -0000 Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 84.19.169.162 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 84.19.169.162 mail.experimentalworks.net Received: from [84.19.169.162] ([84.19.169.162:50608] helo=mail.experimentalworks.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CF/E3-18680-15D15795 for ; Sun, 23 Jul 2017 18:04:02 -0400 Received: from kuechenschabe.fritz.box (ppp-46-244-163-191.dynamic.mnet-online.de [46.244.163.191]) by mail.experimentalworks.net (Postfix) with ESMTPSA id B40BD5EF48; Mon, 24 Jul 2017 00:03:58 +0200 (CEST) Message-ID: <1500847438.16819.86.camel@schlueters.de> To: Kalle Sommer Nielsen , Mathias Grimm Cc: Sara Golemon , Niklas Keller , PHP Internals Date: Mon, 24 Jul 2017 00:03:58 +0200 In-Reply-To: References: <1500551058.16819.47.camel@schlueters.de> <1500584492.16819.71.camel@schlueters.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] bugs.php.net website From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) On Fr, 2017-07-21 at 18:12 +0200, Kalle Sommer Nielsen wrote: > > I would like to come up with a basic MVP that we could iterate > > until at > > least someone is happy :) > > For the MVP my idea is to keep functionality exactly the same as > > introducing new features will make us not ship it ever. > > First create a rock-solid base and then add features. > > > > So, for that I need to know the hard limits, the DOs and DON'Ts to > > set some > > boundaries. > As for DON'T's, the main ones would be as I wrote about: >  - No global variables mess, a global variable for database access > shared across procedural functions are perfectly fine tho, and same > for others on a case by case basis >  - No need to implement third party libraries for things essentially > possible in native PHP. We should be neutral, if we use some library, > it can be interpreted as PHP.net favors this or that PHP based > project It is also good for the PHP ecosystem at large to show we're using libraries, where it makes sense. If we use a variety we're also not favoring single ones :) >  - No need to overcomplex code by using practices such as MVCs, we > got > the browser as our front controller. We can create abstractions for > commonly used operations, such as comments, bug reports and > authentication objects > A reason for this is that these sites are not "actively developed" and it should be possible to find the relevant code within a few minutes, even when looking at it every second year or though. With the current architecture I go to search.php's code and can see what's going on. With a framework I have to see how the framework handles the routing and where the relevant controller is and so on and so forth ...  this is contrary to other projects under constant development possibly by larger teams and is also different from developing a generic bug tracker (or whatever site you look at) where things need to be configurable for different usage scenarios ... johannes