BuddyPress.org

They will usually not show up as members in the front end members section until they login for the first time. That may be why the numbers are off. This is at least what I have noticed on my install.

The answer to those questions was touched upon by JohnJames earlier, a few posts up.

I would love to see really good docs, but it’ a tough challenge, and as said ‘not sexy’ and although rewards not really the point scant recognition for ones efforts, were you aware I contributed one particular page took me almost a day to do it well, testing each point to make sure it was accurate, some ten revisions later by various people and I may as well have not bothered, was it improved ? debatable but probably, that I added the detail to start with more the point ? perhaps, not really sure though so you see one of the issues

@hnla point taken but no one is paying the core development team either so why is their no initiative set for codex documentation? If there are people willing to take their time to create free software then why is there none to document the codex? I could see a huge leap forward in development if these up and coming coders have the vital documentation that would allow them to produce quality features and plugins.
Edit:
My point is simply give people the documentation they need to participate. There is strength in numbers and when you have a slew of educated coders at your disposal then anything could be achieved within this project. Its basically allowing us to help you. If we do not have the keys to do this, I could see this project reaching a plateau and future development ceasing!

However @ethanvan can we keep things on site please not off on private emails, we have already a group or thread on codex matters lets try and keep focussed there.

I agree about the sentiments re attempting to mirror WP codex as much as possible.

We don’t simply want a long list of hooks/filters though we have a complexity of functions that need describing , also we need to explain the basics of how BP works in terms of navigation, core templating etc it’s not straightforward and not strictly in keeping with WP we need examples of how to create new nav items, update and improve examples of the primary loops, group extension etc

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.

erm all developers hate documenting, I loath it no one pays me to do so I always look at stuff shake my head and sigh as I realise I must document something in detail. I fully get what modemlooper means I code, anything that stops me coding, project management, tickets, writing docs etc, all things necessary to my working life I loath, an absolutely necessary evil and project management vital but I just want to make the code stuff that makes stuff happen so I can sit back and smile.

I wasn’t trying to sound dismissive. There are many users of BuddyPress that can easily contribute on the user side of documentation. My statement was in regards that my time is better spent on development of features/plugins. When I have free time I write in the codex.

That error will usually happen when you try and use the template pack with a theme that is already designed for BuddyPress. Are you sure that’s not what is happening?

You cannot delete the call to footer.php in the template file as you’re now missing the closing tags for the containers for some divs, article, as well as closing body and hmtl tags.

1. Let’s go back to deleting the 6 folders.
2. Then Re-run Appearance > BP Compatibility.
3. Then upload the header-buddypress.php and sidebar-buddypress.php as I have instructed in this post https://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/buddypress-issue/
4. Then STOP and post here so I can see what’s wrong. Do not remove anything as it might just be a matter of adding a style or so in your themes’ style.css file

Thanks @djpaul as @hnla noted above and @modemlooper seconded, we do need to conduct Codex audits – one from Users perspective and the other for Developer’s.

In that vein, I suggest we have leads for both Users’ and Developers section and create a new Group Forum for the BP Codex Group here e.g. https://buddypress.org/community/groups/bp-codex/. Work together on the audit, then post what pages need to be created, updated, archived, etc. and create call to action for volunteers/group members to own the page/s which can be reviewed later on. I’m willing to help lead the User’s section and also work on codex pages for Theme Development.

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

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

If you are using the BuddyPress template pack then deactivate it.

You use the groups extension API https://codex.buddypress.org/developer-docs/group-extension-api

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.

@misterhill

1. Initial scan reveals that we can make the templates compatible by creating two/three files only and uploading it to your theme folder in server. The thing is, the page title won’t look like the “Contact Us” title on this page http://themes.blahlab.com/vagenta/?page_id=70 but would be within the content area of the left column. If you prefer that the page titles on the BP templates look like that of “Contact Us” title, then you’d need to revise 16 BP template files

I would opt for creating two/three files only intead of revising 16 files. What say you?

2. Either way. Open up your theme’s header.php file, copy all source, paste in pastebin.com, click submit, and post the generated URI here. If you haven’t changed anything in the header-buddypress.php as well as the code for the page.php posted in pastebin links posted above, no need to repost. But I need you to paste your theme’s index.php, loop-page.php, sidebar.php and footer.php files in pastebin and post the pastebin url’s here.