At slightly short notice (although briefly mentioned last week on slack) I’m resuming the template chats for Thursdays @ 20:00 utc ( or earlier if it suits more people? )
As today is at short notice the chat is a more informal one to get the ball rolling again and I hope anyone that is interested will check in and lend a voice.
We’ll keep to a short meeting of 30 mins – depending on how things go this might roll on longer.
As the Nouveau project is in a fairly complete state vis a vis templates, styles, majority of the directory structure, functions/classes etc this is the opportune moment to discuss the areas that will dictate how the template pack is managed and executed in BP core and these areas to some extent dictate how work on the project in general moves forward.
The discussion points are therefore:
- Agreement or otherwise that template packs or templates are run in the core bp-templates folder.
- If running from core do we want to implement the template switching process? See ‘UI to Pick Template Packs‘ Trac ticket & to be considered in this point is that imath has effected a very effective solution here currently in use if running Nouveau as a plugin
- If we do run multiple templates – what if any are the implications of supporting these multiple packs in terms of time updating them if required?
- In terms of styles I’ve followed a ‘partials’ approach to breaking the various components into smaller file includes compiled into the main .scss sheet, the principle notion here was that those ‘ _partials’ are maintained in <code>/src/bp-templates/shared/styles/</code> and can be used as a base set for any new set of templates (obviously not being compiled into the ‘build’ for final releases). Although I have kept things flexible so we have options I think this best approach so would seek consensus &/or opinion here.
There is a fair bit to discuss just in the points above, ideally we seek consensus on these points so we can move forward but am not expecting we can achieve this in one chat session but making a start is the important thing.
Hope to see as many there as possible.
P.S. Please feel free to leave any comments about the points above or any other thoughts on the Nouveau templates project.
P.P.S. The template pack is available here on the BuddyPress github account ‘Next Template Packs‘
- There are currently 83 tickets in queue ( 69 open, 14 closed).
- January 4, 2017 – Beta 1
- January 18, 2017 – Release Candidate 1 (string freeze)
- January 25, 2017 – Target release date
BuddyPress 2016 Survey Extended
The survey period has been extended to December 15, 2016. https://buddypress.org/2016/11/2016-buddypress-survey-site-builders-developers/ Thanks for your participation.
Slack log: https://wordpress.slack.com/archives/buddypress/p1480536140001738
Hey, remember REST API endpoints? Let’s build some for BuddyPress.
We’ll be holding a one-hour discussion to reignite the BP REST API project, at 1900 UTC on Tuesday, December 13, in #buddypress on Making WordPress Slack. A rough agenda for the meeting is as follows:
- What work has already been done on building endpoints? See eg https://github.com/buddypress/BP-REST
- Assuming that we can’t build every endpoint at once, how should we prioritize? Some possible topics for discussion:
- Which component is most representative of BP content, such that we should use it as a blueprint for other component endpoints?
- Do we start with read only, vs read-write? How does the authentication problem affect this question?
- Where can we start using the API in BuddyPress itself? bp-nouveau? The Dashboard?
- What are some other projects that might serve as prototypes for the API in progress?
- What kind of architectural planning needs to happen before we can start building? Things to think about:
- Certain actions, such as the CRUD actions, are common to various BP content types. BP core functions are not always consistent in naming conventions about them (‘insert’ vs ‘create’, etc). Here we have a chance to standardize.
- We should strive for a consistent parameter vocabulary across components. For example, if you pass a
user_id parameter to
bp_has_groups(), you get a list of groups of which the user is a member. But if you pass a
user_id parameter to
bp_has_activities(), you get a list of activity items created by the user. What concepts are shared across the components?
- What kind of model for development and integration into BP core should we pursue? How much do we try to develop as a plugin before merging?
- Who’s in? 🙂
This is more than we can solve in a single session, but it should give you some ideas of the questions we ought to think about before we dive into crushing code.
See you next Tuesday!
Release date: TBA
- There are currently 4 tickets in queue.
Can’t upload profile images in Microsoft Edge browser (#7360) Has patch.
Empty date profile fields can return the epoch date (#7351) Has patch.
Notice: Trying to get property of non-object (#7329) Has patch.
readme.txt: Remove link to recommended plugins (#7328) Has patch.
BuddyPress Component Maintainers – If you’re interested in contributing to the project, please feel free to comment in the post.
XProfile: do not store serialized arrays for multi-value profile field data (#6789) @offereins will take this on as his first component maintainer ticket.
BuddyPress 2016 Survey
If you haven’t taken the survey yet, please take this opportunity to contribute to the development of BuddyPress for 2017. The survey for BuddyPress Theme/Plugin Developers and Site Builders will be closing next week. Thank you!
Slack log: https://wordpress.slack.com/archives/buddypress/p1479931221001345
@slaffik has been reviewing old tickets, closing some, adding others to 2.8, and “providing feedback where I see fit.” A friendly reminder to core devs to review tickets marked with `2nd-opinion` and `dev-feedback`.
Welcome to our New Committers!
Congratulations to @slaffik and @netweb and @offereins for getting commit access! We all look forward to working with you in making BuddyPress greater than ever 🙂
Banners for the BuddyPress 2016 Survey
@johnjamesjacoby has added banners linking to the BuddyPress 2016 Survey at https://buddypress.org and https://codex.buddypress.org The survey will run through November 30, 2016.
Bumping Required WordPress Version
BuddyPress 2.8 will require at least WordPress 4.3. (#7350)
Slack log: https://wordpress.slack.com/archives/buddypress/p1479326430001024
In accordance with our WP compatibility policy, BuddyPress 2.8 will require WordPress 4.3. See https://buddypress.trac.wordpress.org/ticket/7350.
All the BuddyPress development takes place in Trac. All the tickets, most of the feature discussions and confirmed bugs, are all managed via Trac. For better tickets management, we use milestones, components, keywords and other ways to categorize everything. So far we have 24 components:
WordPress (as well as some other OSS) uses an interesting approach where a person or a group of people are responsible for a specific component of a software project. The contributors have a specific interest in their chosen component, and enjoy or see the need to focus most of their contribution time on it.
In the long run, this helps that contributor quickly triage tickets in their preferred component, as they specialize in it and build up a knowledge advantage. The overall project benefits by faster review and prioritisation of new tickets.
I propose to implement BuddyPress component maintainers, with the hope that this will help move development even further and faster.
Some components, like Activity, Extended Profile, and Groups, need special love, as the number of tickets there is 50+. These components will benefit from having multiple component maintainers assigned to them.
Component maintainers don’t need to do anything special – just consider reviewing Trac tickets for your component, when you have a will and time to contribute to BuddyPress. You will be expected to look through all existing tickets, as well as new ones, provide feedback and help the larger project prioritise bug fixes and new features.
If you have any thoughts about this, or want to volunteer to become a component maintainer – please write in comments. And remember, it’s good to have several people per component, so join in even if you see someone’s mentioned your favorite component!