[buddypress-trac] [BuddyPress Trac] #8148: A new direction regarding optional components management
noreply at wordpress.org
Mon Oct 21 23:39:45 UTC 2019
#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
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/>
More information about the buddypress-trac