Skip to:
Content
Pages
Categories
Search
Top
Bottom

Search Results for 'buddypress'

Viewing 25 results - 25,676 through 25,700 (of 69,106 total)
  • Author
    Search Results
  • EthanVan
    Spectator

    Lol you should @modemlooper. It works… sometimes. ;)

    modemlooper
    Moderator

    `I expect that I should be allowed this privilege solely on the basis that I am willing to do so`

    I’m using this in every job interview from this point on. *snort

    EthanVan
    Spectator

    I didn’t realize that MediaWiki powered the WP codex… I quite like the WP powered codex idea I just meant that the BP codex should be organized like it is at WP.

    @johnjamesjacoby – It’s already been admitted that the last attempt at the codex was a fail due to lack of leadership and everyone just doing whatever… So keeping that mentality is futile and is holding back the success of the codex. I’m not here to kiss butt and brown nose. I’m here to do a job that I won’t get paid for that will help YOU and YOUR project immensely because it needs to be done. Don’t get righteous about “earning the right” to be a leader of the codex team when your plan is not to have one.

    Someone should take the reigns and build a structured codex team and I see no other person stepping up except myself. I expect that I should be allowed this privilege solely on the basis that I am willing to do so, and additionally, have many years of leadership experience. If I fail, you lose nothing and get to have a laugh at me, but if I succeed, the amount of praise and respect BP will gain will be immeasurable.

    So, please let us put our pride away for a minute, stop addressing leadership rights, and concentrate on organizing a codex team and getting it structured in a way that lends itself to productivity and direction.

    I agree with you @hnla we need to stay focused. I realize we need to have a deeper scope within the codex. What I think should happen first though is building the lists and descriptions of functions, hooks and filters, the reference. Then we have a base page for everything. Later we can go into deeper coverage and provide example code etc.. Any project this large needs to be completed in phases.

    @modemlooper, @johnjamesjacoby, I don’t feel dismissed, the codex was being dismissed. Anyways, that’s going to change.

    The very, very first thing I think should happen is setting up a clean slate to build on. Keep the codex up as is for now but give me a new, private, clean slate to create version indexes and add pages for each function, filter and hook. We can point to the new codex when phase one is complete. The reason I want to use pages is so I can implement a parented structure. Are there any objections to this? Any other ideas? Anyone wanna slap me? ;)

    #145361
    @mercime
    Participant

    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.

    My point is simply give people the documentation they need to participate.

    Is there something preventing you from doing this that I can help with?

    The “if you don’t do %, you’re going to lose %” attitude isn’t a great motivator; it’s leading with fear, which isn’t how I choose to lead my projects. Future development will cease when the project is no longer relevant; that will be a sad day, but it isn’t anytime soon. BuddyPress is as strong of a project as it’s ever been, so worrying about it’s future is wasteful.

    modemlooper
    Moderator

    Going over that team link which I had totally forgot about. Some good info. I am moving this thread over there. I have a suggestion to get it rolling. https://codex.buddypress.org/team/

    #145356
    drill_sgt.lewis
    Participant

    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.

    Hugo Ashmore
    Participant

    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

    drill_sgt.lewis
    Participant

    @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!

    Hugo Ashmore
    Participant

    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.

    Hugo Ashmore
    Participant

    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.

    buddhatunes
    Participant

    disabling all buddypress themes did not work

    modemlooper
    Moderator

    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.

    buddhatunes
    Participant

    So, would I network disable all buddypress themes?

    #145343
    aaclayton
    Member

    Hey @themightymo,

    I did try SI Captcha, I was getting a strange PHP error by which the code was never successfully validated (even when entered correctly). I ended up settling on Sweet Captcha, which is a pretty neat idea, but it’s one of those annoying plugins that inserts a ton of sitewide javascript and css rules, so I’m working to hack these out with the exception of the register page.

    I would still be interested in knowing how to filter user registrations though, in addition to whatever Captcha method I use I wouldn’t mind adding a honeypot as a redundant safeguard.

    EthanVan
    Spectator

    I noticed that when you click on the version numbers in the current codex you get notes about the release. IMO that’s wrong. Release notes should be clearly divided into their own section. Those links should lead you to that version’s codex index. Also, I don’t think we need to have those posts showing there below the codex, not to anyone who isn’t administrating it. That just distracts people. The access to editing the codex should be restricted to the codex team. This will eliminate the possibility of vandalism or misinformation.

    I wish I could restructure it, however I have no access to moving things. At least that’s the way it appears. I would copy the WP codex structure exactly and insert the information just as it is in the WP codex if I could be allowed to do so.

    I’ll setup a project manager for this and we can get some real good done. Core team, do you have a place that I can setup a project manager for the codex or do you have one already? Any help in this area would be greatly appreciated. Aslo, what about getting prerelease heads-ups and notes say…two weeks before a release happens so I can make sure that the codex is updated either simultaneous to or previous to the new release?

    Tasks that need to be done (for each version) are:
    * List all of the hooks in a text file.
    * LIst all of the filters in a text file.
    * Describe all of the hooks in a text file.
    * Describe all of the filters in a text file.
    * Rebuild the current codex structure to mirror the WP codex.

    Creating a simplified plain text based prerelease notification system that I can use to keep the codex ahead of releases would be incredibly awesome.

    Example: “hook_name/function_name/filter_name” – “very brief description” [path/to/file-name.php:line#]

    Codex contributors are as equally important as the core team, period. These two teams compliment each other and need to be recognized as equals by the whole community. As a contributor to the codex you ensure that plugin developers have all the information they need to provide full compatibility and more reliable plugins.

    If there is something I missed PLEASE point it out to me! We need to have every duck in a row for this to be successful.

    Tammie Lister
    Moderator

    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?

    buddhatunes
    Participant

    Just confirmed that it is a bp-template pack issue. How do you recommend I integrate buddypress with other wp themes then?

    #145339
    @mercime
    Participant

    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

    EthanVan
    Spectator

    @Boris – Release often release fast is only good for monetized projects that have a well organized and paid team that keeps the same file structure AND hook/filter names OR has a paid and dedicated documentation team. Just because you can link to a wikipedia on your point doesn’t mean it’s correct.

    When you start releasing completely different structures in each new version you ruin it for the open source community without having proper documentation. Period, no argument can be made against that fact.

    @djpaul – When releases completely change the codex, yes it does have a direct correlation. Are you not seeing the drop-off in new plugins? I wonder why that is… Three releases per year is doable and the codex could catch up if you maintain the current structure and only add new hooks or filters. The whole community is struggling to get insight into the new structure.

    From my perspective it appears that the core team holds themselves above documenting, as if it would belittle them. Specially after reading @modemlooper ‘s comment; “Also I feel some of the non developers in the BuddyPress community should jump in to contribute. If i had more time i would but i use my time for development not documentation. Thanks for your effort!”. That comment is dismissive at best. How do you expect non-developers to write a codex for something that you need to understand code to write? Talk about putting your foot in your mouth.

    I do agree with you about structuring the BP codex based on the WP codex. Great idea @modemlooper.

    The key to leadership is positive reinforcement and assurance. By having people just do whatever you create a pool of uncertainty. What this codex project needs is a leader that can assure contributors they are doing a great job and assign tasks so each contributor can say; “that’s the section I’m in charge of”.

    I’m glad I sparked up this conversation, it was much needed.

    #145334
    mgkoller
    Participant

    To clear things up the div class inside the “dashboard > Activity” is

    `

    @mercime
    Participant

    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.

    #145331
    flyj4ck
    Participant

    yes i did rerun and its even worse cause then sidebar is under it
    so i deleted sidebars and footers from all bp pages

    now i only need to fit bp pages insted theme , cause they going out to the right a little.

    #145330
    Toriea
    Participant

    @mercime Ta very much for that. Installed the plugin now and am checking it out.

    I’m still not getting the Codex, my end!

Viewing 25 results - 25,676 through 25,700 (of 69,106 total)
Skip to toolbar