[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 johnjamesjacoby):

 I'm going to provide a series of responses. Anything that reads as me
 disagreeing, is just me poking holes in ideas to try and have a dialog,
 and isn't meant to be shutting anything down or being negative.

 1. The hugeness shouldn't bother us. BuddyPress provides immense value at
 a third the size of WordPress. This was an original concern with the folks
 working on BP Media, needing to package huge codecs and such. It could
 easily be that for BP Attachments, too. But... things are what they are.
 If it takes 50MB to solve the problem ''correctly'', so be it!

 2. Core + Members doesn't really provide a whole lot of intrinsic value,
 because those Members still can't do anything but comment. They won't even
 have profiles (well... they'll still have the non-extended ones, provided
 that still works!)

 3. This was always a great idea, and one I'd like to see come back
 somehow. It's somewhat of a maintenance burden, about the size of what the
 Plugin Review team does already. To fully implement this, we'd likely want
 to communicate what our intentions are, and make sure to be available to
 them.

 4. If a component inside of BuddyPress needed love, and if we had the
 time, we could release a new version with enhancements to any core
 component at any time. Everything being in a monolithic repository hasn't
 prevented progress yet. Similar to WordPress, I believe there is still
 immense value in everything being "packaged" together natively, rather
 than requiring additional research & discovery.

 5. In an ideal world, every component could have alternatives, including
 Core & Members. If these components are "native applications" inside of
 BuddyPress, they should be hot-swappable, to allow some other
 different/better component to take their place. Deep within the Core of
 BuddyPress, this is actually achievable, though I've seen zero people take
 advantage of this ability or API.

 6. Absolutely agree with this. Leveraging the existing WordPress.org
 plugins repository is definitely the way to do this. There's literally
 nothing currently to gain in maintaining a separate system.

 7. The Components admin screen was specifically modeled after the Plugins
 screen, so that it would feel familiar. Many different plugins with their
 own ecosystems have invented much more tailored UI than what BuddyPress
 has, 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.

 8. People are able to use the WordPress.org repository currently, and we
 had previously pulled plugins in tagged with "buddypress" into a page on
 buddypress.org/plugins, but the duplication and fragmentation was weird
 and unappealing to most users. In addition, we used to use BuddyPress
 Groups and Group Forums to give them all a place to offer support. All of
 this is still re'doable, but it's hard to know if these are things we need
 again, or things we could do, or want, etc...

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