BuddyPress.org

There’s a plugin https://wordpress.org/extend/plugins/buddypress-activity-plus/screenshots/
If you find any issues with the plugin, please post at https://wordpress.org/support/plugin/buddypress-activity-plus

Please post support question for Activity Plus plugin at https://wordpress.org/support/plugin/buddypress-activity-plus

@zaniwhoop please start a new topic next time. The code used from 2 years ago won’t work for current BP versions. Closing this one.

For your reference, this tutorial by pcwriter is pretty thorough http://wpmu.org/how-to-build-a-facebook-style-members-only-wordpress-buddypress-site/

@raminjan Sorry, not sure what you mean. Please clarify. By “wordpress buddypress comment box”, are you referring to the comment form in BP Default theme’s single.php file or to the Activity Stream comment form or something else?

Codex pages can be created through wp-admin, like any WordPress site: https://codex.buddypress.org/wp-admin/

This is a meritocracy. http://en.wikipedia.org/wiki/Meritocracy While you’re free to air your suggestions, you are not free to become abusive to anyone in this forum or anywhere else in the WordPress ecosystem. Know that we are free to lock the topic and delete posts https://codex.wordpress.org/Forum_Welcome#The_Bad_Stuff

If you want to hire a BuddyPress consultant, please post at https://buddypress.org/community/groups/bp-jobs-board/forum/ or at http://jobs.wordpress.net

Otherwise, create a topic and be specific about what you need answered.

A few things:

Manually writing documentation about code, is an infinite loop, where no one is satisfied. Code changes quickly, line numbers change, hooks change, things get deprecated, and one becomes a bottle neck for the other.

If you want to write pages on the codex, have at it. The taxonomies can change, we can add new ones, remove ones that aren’t helpful, whatever we want. Ultimately, I picked a few taxonomies that seemed to fit the project at the time, just to have *something* since before, we literally had nothing at all.

Regarding setting up a forum for the codex we have one: https://codex.buddypress.org/team/

Regarding having longer, slower release cycles, it’s not going to happen. If anything, they’ll get smaller and faster, with less code changing more frequently.

Releases shouldn’t be held because of out-of-date documentation, and the documentation shouldn’t wait until the release. It’s a wiki for a reason, and if you’re passionate about doing the documentation labor, you’re free and able to do it. If it’s not satisfying or rewarding for you, no one expects for you to do it. Obviously, we want to create an environment that’s fun to work in, and it’s my responsibility to make sure that happens.

Regarding feeling dismissed, try to keep the negative emotions out of this. No one here wants anyone to feel bad, and the people that do work themselves out. Reread for tone and clarity, and understand that we’re all passionate, and just want to do good things together.

Codex contributors are not more or less important than anyone else, but the BuddyPress Core team is going to make the decisions about code changes and release cycles, and that won’t likely ever change.

The fact is, that documenting an open-source project is neither glamorous nor sexy, an it’s easy to feel like you’re efforts are not appreciated. That last part’s not true, but since there’s no obvious or advertised audit trail, and no reward system in place, people working on the codex are often separated and in the dark about what’s going on around them.

If you want to keep up, you just have to try harder; no one is going to slow down for anyone else. As an example, I’m often in the dark about what’s going on in WordPress core, so I spend an extra 2 hours every night reading through the changelog, testing BuddyPress against WordPress trunk, and generally just spend more time doing more labor. It sucks, but I can’t ask them to slow down production and put their initiatives on hold.

It’s ironic y’all want to move towards the way the WordPress codex; many of their documenters strongly dislike Mediawiki for this purpose, and want to move towards a WordPress based approach like we have here.

Anyways, this is all good and healthy debate, but in the end it comes down to earning the right to have your opinion carry more weight than someone else’s, the old “meritocracy” approach. “Assigning a project manager” isn’t how this works. It’s an open system where everyone volunteers their efforts, and if you volunteer a higher quality of work more efficiently, you win the game and get to start making decisions.

Regarding having ducks in rows, ducks organize themselves into the pattern that suits them best at the time. It’s great to want to lead the pack, but you don’t self-appoint in an established and mature project.

Metaphors and responses aside, what 1 thing can I do immediately to improve the codex experience? Let’s pick 1, and talk about it, and make a decision on what to do about it.

BP Codex is working https://codex.buddypress.org/

Re Group pages, check out https://wordpress.org/extend/plugins/buddypress-docs/

what @hnla said plus I want to add we should use the WordPress codex as a template on how to structure the content. People are familiar with WordPress and it makes sense to display the content as such.

See https://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP

@mercime We had a team but it fell apart after a few weeks. I think it’s because there was no leadership. It was a do anything to help approach and that seems daunting. WordPress has loads more people on development/documentation and that is the reason this codex is behind. Just not enough people/time to get it done. We should bring this up during the dev chat.