Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • hnla 8:39 pm on September 11, 2013 Permalink | Reply  

    Revised Codex TOC Outline

    This outline represents a revised version based in part from the feedback received from the recent codex survey. This revised version is subject to the comments and views of everyone and can be updated if sufficient comments concur on an aspect.

    Introduction – Primary landing page

    The actual codex landing page has been re-factored to follow this outline but can be changed.

    Section 1: Intro

    Introductory text- possibly stating the obvious? and could be removed?

    Section 2: Main codex Areas – linking to parent page for sections.

    • For Regular Users
    • For Theme Builders
    • For Developers

    Section 2: Contribute

    Guidance on how people can get involved with the BP project – links to two pages ‘Codex formatting guide’ & general Participate & Contribute’ page with full BP project links

    Section 3: Version list & changelogs

    Links to full list of all BP version releases – updated to include links to zip downloads.

    Section 4: Legacy docs – all docs prior to 1.7 are removed to this section

    For All Users
    Getting Started
    • Before Installing
      • System & Server Requiremets
      • Plugins > Add New
      • FTP/cpanel
      • Securing install – backups etc ( guide exists)
    • The installation process overview
    • BuddyPress Components and Features Overview
    • Using BuddyPress with WP MultiSite (guide to using BP with MS – how bp functions with subsites) new page

    User Guide

    • Introduction (page parent, right hand sub page menu) -
      • Configuring BuddyPress
        • Settings > BuddyPress > Components
        • Settings > BuddyPress > Pages
        • Settings > BuddyPress > Settings
    • Managing Components
    • The registration process ( overview of reg process, email, activation, extending reg fields using xprofile fields) NP
      • Activity Stream Admin Panels
      • Group Management Admin Panel
  • Languages & translations, labels
  • Frequently Asked Questions
  • Tutorials(1)

    • For Theme Builders

    • Introduction (page parent, right hand sub page menu) – covers the essential principles for building sites / themes e.g. Standalone, working as child theme, clarifies bp-default/bp legacy.
    • BP Theme Compatibility 1.7 ( overview section )
      • intro to theme compat 1.7
      • The template hierarchy in detail
      • Upgrading template packed themes to theme compat
    • Building themes ( general pages covering actual approaches to theme building )
      • An overview on the various approaches one can take in managing BP templates/themes (N)
      • BP Default Child Theming
      • Working with BP Legacy -Theme Compatibility (N)
      • Building from theme compatibility templates in custom theme (N)
      • Building themes using Template Pack
      • BP Theme Unit Test – ala WP Theme Review Test – BP Default Theme and Twenty Twelve theme – @mercime already started this then stopped to create those BP Component Pages in Codex
      • Tutorials(1) ?

    For Developers

    • Introduction (page parent, right hand sub page menu)
      • Template Tags
      • Main BP loops, e.g. members loop, activity loop etc.
      • Functions list ?
      • Conditional Tags
      • Building and extending components, working with Queries.
        • Extending BP user account screens
        • Extending Group component
        • Working with the template stack / extending BP_Theme_Compat (N)
        • BP_User_Query (N)
      • Developing plugins for BuddyPress
      • Developing for BuddyPress & WP MultiSite
        • Guide to how BP functions with MS – intro page, new.
        • User Submitted Tutorials/code snippets –
      • Unit Tests
      • How To(1) – General ( collects series of shorter examples of how to do something e.g. ‘force ssl admin’)
      • develop.buddypress.org (PHPDocs)

    Feedback on this proposed structure, suggestions for improvement is welcome and hoped for.

    Snipped from the codex survey is this comment Please make something scalable that won’t be obsolete by the time 1.9 comes out! and is something we try and bear in mind moving forward. This codex structural revision needs to be something we can build on and that serves to clearly manage pages under a clear hierarchy that allows people to quickly find the information they are looking for, to that end w welcome comments and feedback on the nature of nesting pages under sections, are there too many? Are pages buried too deeply? based on the old paradigm that any web page should not be more than three or four clicks away how do we stack up on that score?

    With the developers section certain information such as references to ‘Actions’ will be provided by PHPDocs to be implemented for the Codex.

 

  • Mercime 5:52 am on September 6, 2013 Permalink | Reply  

    The 2013 BP Codex Survey report is now available. Read about it at http://buddypress.org/2013/09/2013-buddypress-codex-survey-results/

     

  • Paul Gibbs 11:39 pm on August 27, 2013 Permalink | Reply
    Tags: future release, ,   

    How do we stop Trac’s “Future Release” milestone becoming a graveyard?

    Or, what should we use the Future Release milestone for?

    The issue is that we get tickets with good ideas or, in some cases, small bugs (or big bugs that we know will take several releases to resolve) that don’t fit into the current release roadmap, the ticket is moved to Future Release. These tickets almost always rot there unless a contributor does some work on a change, and we move the ticket back to into a release.

    Over time, this builds up and currently we have 439 tickets in there.

    Interested in any ideas because the way we’re doing it now just doesn’t scale.

     

    • trishasalas 12:36 am on August 28, 2013 Permalink | Reply

      What about something like a Bug Gardening that WordPress does? It wouldn’t fit for all tickets but perhaps we could either create sub-categories (does trac support this?) or additional categories with the same workflow in mind. i.e. Let’s keep this in mind, look at them on a regular basis and keep it clean.”

    • Boone Gorges 1:19 am on August 28, 2013 Permalink | Reply

      I think it would be good for someone to go through the milestone at the beginning of each dev cycle and highlight items that are worth looking at. For this many tickets, it’d probably take a couple people a few hours during each cycle. Maybe we could call for volunteers to take a handful (50? 100?).

      • Tammie Lister 4:33 pm on August 28, 2013 Permalink | Reply

        I’m all for sprints and happy to be part of it, problem with a sprint is people not knowing what is future or not. Maybe that’s at least part of the issue, just putting in a bucket because no phases to put into?

    • imath 11:25 am on August 28, 2013 Permalink | Reply

      This week-end, i’ve read the 439 tickets titles and found some interesting ideas, for instance i’ve suggested a patch to #2673 and #2242. I am very interested to explore #5027, #3764 and #2742.

    • danbp 1:53 pm on August 28, 2013 Permalink | Reply

      What is exactly a “feature request” for a end user point of view ? I presume most of the BP users go on the Trac because they encounter a bug, not for dispatching some dev work.

      If “feature request” means “Give us a new idea to add to BP”, the form should be very explicit to do so.
      It’s not the case actually. When a user fill in the form he got as default deposit reason defect(bug) or can choose for “enhancement” or for “task”. Wow ! No wonder if the “feature request” tickets are mostly marked as defect(bugs) or enhancement.

      That let’s suppose that a “feature request” is something like a consolidation or an expansion of something missing in the current code, or in some case, simply missing (a la would be nice to find “this” in a next release…)

      Aside some bug reports, who are not really bugs and not really important defectuosity generator. OK. So the ticket moderator will put them under the pile for “a coming soon” analysis – in other words, ” we’ll study this case later. Perhaps”. This brings some remaining tickets (3 years since opened for the first time) like this one: http://buddypress.trac.wordpress.org/ticket/2372

      This is no more a ToDo with a milestone, but a claim average dependant work probably…. ;-)

      Of course my piece of cake doesn’t answer Paul’s question: what do we do with the existing “feature release” tickets mountain. I’m affraid that Trishasalas and Boone are right. Roll up our sleeves and dig !

      Unnless you accept the idea of closing the feature request to the public and handle this status internaly. This can be done when a ticket is moderated. The feature list stays readable but wouldn’t be publicly editable.

      • Paul Gibbs 2:26 pm on August 28, 2013 Permalink | Reply

        A feature request is often the same thing as an enhancement, and it’s when someone suggests something is added to BuddyPress, and that we agree it would be nice to add.. someday.

    • Paul Gibbs 9:11 am on August 30, 2013 Permalink | Reply

      I’m thinking something dramatic like closing all Future Requests over 6 months old (387 tickets). Not because they mightn’t be good ideas, but if we haven’t prioritised work on them yet (and no-one else has), they’re probably not going to do this soon.

    • Renato Alves 12:12 pm on August 30, 2013 Permalink | Reply

      I know that it would be hard, but what about taking two or three people to work only on those tickets?

    • Mercime 2:30 am on September 11, 2013 Permalink | Reply

      Thanks for the reminder Paul! Checked out tickets I reported which are currently open and posted recommendation to close 3 tickets. As of this minute, @r-a-y has closed 2 already cool :-D

  • Mercime 4:01 pm on August 23, 2013 Permalink | Reply
    Tags: , survey   

    The BuddyPress Codex Survey will end on Monday, Aug. 26th at 19:00 UTC. http://mercime.polldaddy.com/s/2013-buddypress-codex-survey

    Many thanks to everyone who has participated in the survey so far. We’ll be posting the results later next week.

     

    • slaFFik 4:15 pm on August 23, 2013 Permalink | Reply

      Very interested in results :)

      • Mercime 4:19 pm on August 23, 2013 Permalink | Reply

        Thank you for volunteering to help with the Codex :-)

    • Paul Gibbs 11:29 pm on August 27, 2013 Permalink | Reply

      When do you present the results?

      • Mercime 11:51 am on August 28, 2013 Permalink | Reply

        Currently analyzing and categorizing the results. We will be posting the report here right after we send copies to the BP Devs this Friday or Monday next week. Thanks for your patience :-)

  • Paul Gibbs 11:40 pm on August 21, 2013 Permalink | Reply
    Tags: developer documentation, phpdoc   

    Worth keeping an eye on the work happening on the WordPress dev site about standardising phpdoc markup for actions and filters:

    http://make.wordpress.org/core/2013/08/09/better-inline-docs-for-3-7/

    I think they are going to post another update soon about whatever they format standardise on, but this is something BuddyPress should also try to do going forward.

    For the record, BP has 2614 actions and filters:

    $ grep -iR “do_action” * | wc -l
    1306
    $ grep -iR “apply_filters” * | wc -l
    1308

     

  • Mercime 4:27 pm on August 16, 2013 Permalink | Reply  

    @hnla and I are in process of improving the documentation for BuddyPress. Help us by taking a few minutes to answer the 2013 BuddyPress Codex Survey.

    Take the survey.

    Thank you so much for your time and have great weekend :-)

     

  • hnla 8:52 pm on August 6, 2013 Permalink | Reply
    Tags: , Codex outline structure   

    As part of the 1.9 release cycle it was considered time to focus some much needed energy on the BuddyPress documentation. There have been many great new features and improvement to BP over the last three releases and we need to bring the documentation up to date with them. While the community has contributed pages and guides to cover many of these, such as theme compatibility, component API etc, what is desperately needed is a solid review of the codex structure and audit of existing pages.

    So the Codex Review is a two stage process:

    The first stage is to present an initial outline structure  – as seen below on this page – this has been prepared by @mercime & @hnla.

    The second stage is a full audit of all existing pages to check if they are in need of updating, or archiving as no longer relevant, and to highlight new pages that are required on topics.

    The outline below is our suggested starting point and we encourage everyone to add comments and suggestions from which we can further modify and improve this structure.

    Proposed outline – main codex sections & preliminary sub-sections/pages

    A. Introduction

    To include links to legacy docs ? and version downloads plus any relevant useful links

    B. Getting Started

    • Before Installing
      • Installing BuddyPress
        • Plugins > Add New
        • FTP/cpanel
        • Securing install – backups etc ( guide exists)
    • BuddyPress Components and Features

    C. User Guide

    • Introduction (page parent, right hand sub page menu) -
      • Configuring BuddyPress
        • Settings > BuddyPress > Components
        • Settings > BuddyPress > Pages
        • Settings > BuddyPress > Settings
    • Managing Components
      • Activity Stream Admin Panels
      • Group Management Admin Panel
  • Languages & translations, labels
  • Frequently Asked Questions
  • Tutorials(1)
  • etc. etc.

    • D. Theming – building sites with BP

    E. Developer Documentation

    F. Contributor Guide
    This could be placed on the general intro page?

    G. Archives (Legacy) possibly linked to from intro page

    Proposed Timelines

    This is the proposed timeline for the various stages of the BP Codex Review.
    These dates are not set in stone, but are a suggested as achievable target milestones.
    All comments and suggestions sought and welcomed.

    Aug 6, ’13 Post General Outline for Dev feedback in IRC the next day Aug. 7.
    Aug 26, ’13 Incorporate audit of current content in Outline. Listing of what’s updated and what’s not as well as what needs to be added. For Dev feedback the next day Aug. 21
    Sept. 3, ’13 Post what’s done in bpdevel.wordpress.com as well as BPorg Forums for :
    • volunteers who will create needed content or update specific pages of Codex listed
    • feedback re general outline
    Oct. 3, ’13 Target date for completing first pass at Codex update/restructure per outline.
    • De-clutter: archive or delete old pages.
    • Re-factor the codex structure.
    • Shuffle existing pages into relevant sections.
    • Work with Devs on outstanding Codex articles required for BP 1.9
    Nov. 7, ’13 Codex Target Completion
     

  • Boone B. Gorges 8:01 pm on August 5, 2013 Permalink | Reply
    Tags: , 1.8.1   

    BuddyPress 1.8.1 is now available: http://buddypress.org/2013/08/buddypress-1-8-1/

     

  • Boone B. Gorges 6:47 pm on August 1, 2013 Permalink | Reply
    Tags: , release cycle, schedule   

    [Thanks to Trisha for helping to compile these notes!]

    After the BuddyPress dev chat on July 31, we’ve got some tentative plans for the 1.9 scope and timeline.

    For the 1.8 dev cycle, our experiment with a short timeline and strict deadlines was, by most measures, a big success. We’ve had very few bug reports related to changes in 1.8, and the speed of the cycle meant that nothing sat unused in trunk for too long. We’re hoping to replicate this success by taking a similar approach for BuddyPress 1.9.

    Scope

    We settled on roughly the following major feature set for the 1.9 release. I’ve listed appropriate ticket numbers, along with those who’ve committed to the tasks (though, as always, more participation is very welcome).

    • New template pack (@karmatosed and others; see #4952). This work was begun during the previous release cycle, and we think we’re in a good position for this to be the main user-facing improvement in 1.9.
    • Move user ‘last_activity’ out of wp_usermeta. (@boonebgorges; see #5128)
    • Better two-way sync of activity comments with sources like forum replies and blog comments (@r-a-y and @paulgibbs; see #1419)
    • Migrating to the WP Rewrite API (@johnjamesjacoby; see #4954)
    • Custom Post Type enhancements: better activity stream integration, and better dashboard support for that integration (@trishasalas and @boonebgorges; see #3460)
    • Codex cleanup and refresh (@mercime and @hnla)

    Timetable

    • August 1, 2013 – 1.9 development cycle begins
    • September 26, 2013 – End of new development for 1.9. Beyond this date, nothing gets committed that is not either a bug in a new feature, or a regression from 1.8.x. Any major features from the list above that are not commit-ready by this date will be bumped. Note – The period between Aug 1 and Sep 26 is eight weeks, two weeks longer than the corresponding part of our 1.8 cycle. We’re hopeful that this extra two weeks will give us more time to wrap up big features, and perhaps to focus more specifically on scrubbing old bugs.
    • October 1ish, 2013 – 1.9-beta1. We’ll release the first beta as soon as the cleanup from the dev period has taken place.
    • November 7, 2013 – BuddyPress 1.9 release
     

  • iggOne 11:55 am on August 15, 2013 Permalink | Reply

    I look foward this release !

  • Carl Moebis 8:37 pm on August 25, 2013 Permalink | Reply

    Any chance we’re going to get sub-groups? There appears to be the framework for this buried deep in BP for at least a year, but no progress. If the bbpress side can have sub-forums, why can’t they reside under the buddypress side too, creating sub-groups, or at least showing the subforums under the BP groups? Developers are stuck with the choice of the organizational and structural flexibility of bbpress, but having to exclude the buddypress features (because it becomes redundant). So a user joins a group, but then they have to wade through the forums for the forum/sub-forum tree. Making an admin wonder, why even implement buddypress at this time?

  • isabel marant shop online 8:40 am on August 27, 2013 Permalink | Reply

    For instance, your friend comes and tells you that while babysitting at her neighbor’s one night, she received a threatening phone call that was actually meant for the mistress of the house.

  • Paul Gibbs 6:00 pm on August 1, 2013 Permalink | Reply
    Tags: , roadmap   

    At yesterday’s dev chat, we agreed the scope of BuddyPress 1.9. Very exciting news, and we’ll have a post up soon for people who missed the chat. If you’re super-keen, read the IRC logs.

    A smaller group of contributors had a separate discussion before the dev chat. We discussed the big picture, our thoughts on how we want BuddyPress to grow in the future, and the kind of things that we think we need to do to get there. Boone summarised this well in the dev chat:

    We’ve been talking about some major ways in which BP could be improved over the next couple releases. Some that were mentioned: some media/upload support; better new user experience (NUX) for the new site admin and new site user; privacy/roles/permissions.

    The first two of these are things that are likely to be built as plugins, by teams that include members of the core team but will probably include others as well, and then integrated into core when and if it’s felt appropriate. Kinda like the template pack stuff.

    The last stuff about privacy is quite complex, but there is already a ticket or two in Trac in the 1.9 milestone having to do with some first steps toward having more fine-grained permissions in certain aspects of BP, which’ll create the groundwork for fine-grained privacy sometime down the road.

    Other topics that came up were the codex and buddypress.org, and how important those are towards making BuddyPress approachable as a developer’s toolkit, as well as aid to attracting new contributors to the project (aka selling the dream).

    We don’t expect any of these things to be done by 1.9 but we imagine that work on them will be ongoing through this dev cycle and the next few as well. We’re going to write more dev posts on this blog about these possible projects, so if anyone’s interested in contributing in any way, check back here soon, or you can contact members of the core team directly.

     

    • ← Older posts

    c
    compose new post
    j
    next post/next comment
    k
    previous post/previous comment
    r
    reply
    e
    edit
    o
    show/hide comments
    t
    go to top
    l
    go to login
    h
    show/hide help
    shift + esc
    cancel
    Follow

    Get every new post delivered to your Inbox.

    Join 427 other followers

    %d bloggers like this: