[buddypress-trac] [BuddyPress Trac] #8148: A new direction regarding optional components management

[buddypress-trac]

#8148: A new direction regarding optional components management
-------------------------+---------------------
 Reporter:  imath        |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  6.0.0
Component:  Core         |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+---------------------

Comment (by imath):

 Thanks a lot for your feedbacks @johnjamesjacoby 😍 I agree we need time
 to discuss about this suggestion.

 > BuddyPress provides immense value at a third the size of WordPress

 I agree 💯

 I think there are 2 ways: the BuddyPress or JetPack way (everything is
 inside) and the WooCommerce way (uses Plugins and includes a specific
 Plugins directory). Both ways have advantages and disadvantages of course.

 (The funny thing about this suggestion is that it first came up to my mind
 because of a very limited configured server, I wasn't able to install
 BuddyPress because its size exceeded the Max Upload file size allowed 😆.
 I guess this must be very unusual in most cases).

 > I believe there is still immense value in everything being "packaged"
 together natively, rather than requiring additional research & discovery

 Having features inside external plugins does not necessarily mean there
 are not there when you activate BuddyPress. For instance when you install
 WooCommerce you silently get additional plugins (JetPack, WooCommerce
 Services, the Gateway extension plugin, etc) corresponding to your payment
 options and the first settings you selected during the installation
 process.

 So we can still have the default components there as plugins on first
 install, and make sure to fetch the needed plugins if the ones activated
 are no more included during an upgrade.

 It also does not mean BuddyPress plugins would be maintained in external
 repositories. I believe we can & should carry on maintaining all existing
 and new components from this SVN repository.

 The main difference from having everything packaged against available as
 plugins would be modularity. With the Plugins way, you can easily
 remove/replace a feature completely.

 I simply believe moving to a Components as Plugins model is giving us and
 users more freedom.

 More freedom for users because:
 - they can get what they need at any time without extra "dormant" features
 they don't need.
 - they can have more choices and trust these choices because they are
 powered & maintained by the BuddyPress community.

 More freedom for us because we can try new things without being limited
 with backward compatibility. There's now a huge gap between WordPress 5.+
 and WordPress 4.7 (the version we need to still support) and the gap is
 increasing fast. Having plugins evolving on their side could allow us to
 keep a version making sure to satisfy our back compatibility requirements
 (because I agree it's important) and introduce new versions to satisfy the
 users who would like to enjoy the latest and innovative features or
 "breaking" changes.

 Having a separate & more BuddyPress focused place to install BuddyPress
 components can give some new interests to BuddyPress plugin developers:
 today as you said the WordPress.org Plugin Directory "tag" system is not
 reliable (mostly because of people abusing it probably), that's why I've
 used a specific hand made selection of plugins using a JSON file. We only
 need to make sure this file is hosted outside of the BuddyPress plugin to
 easily update it without updating BuddyPress. The
 [https://plugins.trac.wordpress.org/browser/buddypress/assets assets] sub
 directory of our WordPress.org repo seems a nice place to host it.

 It's also a way to show we are very open (I know we already are) and
 welcoming new contributors seems very important because unfortunately
 we're not eternals and what matters most is the project & not the
 individuals contributing to it.

 > To fully implement this, we'd likely want to communicate what our
 intentions are, and make sure to be available to them.

 Absolutely. If some new contributors were interested to have their plugin
 listed into the "BuddyPress sub directory" or if we were asking a plugin
 author to be listed into it, my suggestions about this would be that this
 would require these authors an "agreement" asking them:
 - to join the team,
 - to contribute to BuddyPress Core codebase and new BuddyPress Core or
 BuddyPress plugins versions beta tests,
 - to contribute to documentations & support forums.
 - to provide at least 3 years of Plugins maintenance and to find a
 successor when they have no more time to maintain the plugin.
 - Components as plugins listed should always be fully featured, free and
 without any ads.
 - TBD.

 One another advantage of only having Core + Members: it would allow some
 plugins to use BuddyPress to provide their front end users profile. For
 instance, users are often asking me "Why do I get BuddyPress users
 profiles, WooCommerce users profiles (or account), ACF users profiles
 etc.. Why isn't it possible to have a unique profile ?"

 > People are able to use the WordPress.org repository currently... we used
 to use BuddyPress Groups and Group Forums to give them all a place to
 offer support

 Yes well, I'd say having more than 54,000 plugins available in the
 WordPress.org repository is great but it's also a problem for the reasons
 you mentioned. Discovering trustable BuddyPress plugins is hard for users.
 There's a project to have a Blocks directory, I think it makes sense for
 us to have a BuddyPress Components Plugins subdirectory inside of the
 WordPress site BuddyPress is activated on. I don't think we need to
 provide something more on BuddyPress.org for example.

 > but I'm generally not a fan of introducing more things to interface with
 unless they are solving other real problems, like accessibility, etc...
 I'm all for making these use a card-like UI, but we should hug closely to
 existing conventions and try not to be too inventive

 Like the the video demonstration shows: it can simply be a replacement of
 the "retired" tab. I know there is a screen in the video/patch showing a
 card style UI, but this screen it there to quickly benefit from the
 WordPress "shiny updates" feature and more precisely from their installing
 queue management. I agree we should simplify this screen and make it look
 like our Components management interface.

 Of course I'm not sure the "Plugins way" is the best way, I feel it can
 improve our modularity. Whatever road we'll take I'm totally fine with it
 👌.

 I'm happy to continue the conversation about this suggestion 😉

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/8148#comment:2>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac