More than ever, the growth and evolution of the Symphony platform is being driven by you—our brilliant and multi-talented (not to mention physically statuesque and uncommonly pleasant-smelling) community members. Over the last few years, you have worked hard to make Symphony your own, and the platform is undoubtedly better because of it.
To further facilitate community involvement and leadership in the development process, we’ve decided to form a set of community working groups that will collaborate closely with the team on specific aspects of the platform (the core, the JS, the UI, docs, and advocacy) and help to solicit and manage input and contributions from the community at large.
What They’ll Do
Each of the five groups will be asked to:
- Develop standards and guidelines
- Monitor issue reports and forum discussions, identify problems, confirm bugs
- Discuss new approaches and potential improvements
- Make official recommendations to the team
- Implement and test solutions approved by the team
- Review and quality-assure community contributions
The working groups will meet on a fairly regular basis, and their meetings and ongoing discussions will be open to the broader community. We’ll be rolling out some new features on the site to accommodate the groups’ activities.
Composition
Each working group will consist of about 3-5 members.
The Core Working Group will be focused on the meaty parts of the Symphony codebase—core classes and libraries, delegates, the installer, and so on—and on the core extensions. It will be led by Brendan Abbott (brendo), a developer at R&B who’s been working very closely with Allen and Alistair, especially on the development of Symphony 3.
The JavaScript Working Group will be focused on the growing jQuery-powered library that drives much of Symphony’s admin interface. It will be led by Rowan Lewis (buzzomatic), another developer at R&B who’s worked closely with Allen and Alistair, and the primary architect of Symphony’s JS library.
The User Interface and User Experience Working Group will be focused on the designs, interactions, and structures that make up a user’s experience of Symphony as a system. It will be led by Nick Dunn (nickdunn), head of user experience at Airlock who is one of the community’s most active and knowledgeable members and has worked closely with the team on just about every aspect of the platform.
The Documentation Working Group will be focused on the system’s user and developer documentation. It will be led by Jonas Downey (jonasd), a relative newcomer who’s already written some fantastic pieces about Symphony. Jonas is a talented designer and illustrator, and has done some great work with infographics—all skills that could help us take our documentation to the next level.
The Advocacy Working Group will be focused on advocating Symphony and its core approaches and technologies. It will be led by Stephen Bau (bauhouse), one of our longest-tenured community members. Stephen is a designer for Domain7 and is a tireless proponent of Symphony, XSLT, and web standards everywhere he goes.
Joining a Working Group
If you’re interested in joining a working group, please send an email to the team (team@ this domain) telling us why you’d like to be considered and what your availability would be.
Comments
The UI/UX WG will have an A-Team van, if that helps.
I pity the fool that isn’t in the UI/UX WG.
Unfortunately it’ll be UK people only from now on because I ain’t getting in no plane.
Nothing a little glass of milk won’t fix!
I want to help, but I just don’t have the time right now. I don’t want to learn that the hard way, again.
Go working groups!
Nick, Brendo: can you make an estimate on how much time beeing on the core team would take?
Brilliant idea.
Woohoo! I don’t think I could be of any help at all, but I will cheer you on from the sideline together with Mark Lewis. Go working groups, go!
Can the A-Team van pull a bandwagon? Keep in mind I’m expecting a lot of people to get on the bandwagon.
Johanna, I think cheering would be a form of advocacy.
I think we should make this a popularity contest. Or a reality TV show.
“It’s time to leave the working group… Tony!”
I can see it now…
Narrator: “For eating the most roadkill while attempting to sell widgets and learn to tango with Paulie Shore, the Docs working group has won immunity for this revision.”
Docs WG: “I’m not here to make friends.”
I’m not sure if this would make another working group but wouldn’t it be an idea to found a group of release testers? I’m not talking about the release candidate cycle I’m thinking of the ZIP download provided on this website: The community has been heavily testing the current core before the release of Symphony 2.1 but we never actually checked the final ZIP download before it was available on this site. Things like a somehow corrupted default workspace should not and need not to happen. If the team could provide a few members with the final ZIP before releasing it, last minute compiling errors could be found easily.
Such a group of “last minute testers” would have to check two things: Does updating work? Does installing the default workspace work? It would be some kind of quality management.
What do you think?
I think this should be part of the RC process, like the final step before the RC is actually announced. It’s a part of testing the RC, after all.
Yeah, you guys are right. We should have some sort of standardized process for doing upgrade/install testing on a release candidate. Don’t know that we need to bureaucratize it though. Maybe once we think a version is ready to go, we just openly post one final RC and ask the community to run install/upgrade tests on it (and we can enlist the WG members with this too). What do you think?
I don’t think that it should be bureaucratized, but there needs to be some kind of process that guarantees that some people are testing this. So pointing at someone saying “This is your job!” might help :)
Is there currently any kind of testing matrix used internally?
Red pill, blue pill?
How do we contact the workgroups if we have general feedback? For now I just opened a discussion on the forum...
Create an account or sign in to comment.