|
Note
|
I’m going to answer on behalf of the CDI specification. |
"" How did you keep your JSR schedule moving forward? Do you face any particular challenges as part of a platform JSR release? ""
I’m not personally involved in the schedule.
I can comment on the release process. The JCP website still lacks sufficient tools to make a JSR release go smoothly. Each JSR still has to take on a lot of the effort to prepare a distribution and publish the artifacts. Having an automated build script or build server available for JSRs would be very helpful here.
"" Is agility a value for you and your Expert Group? ""
Absolutely. One of the biggest complaints about standards is that they move too slow. But, creating a good product takes time, whether or not it’s a standard. Slow and steady wins the race…it’s the steady part that’s been missing.
We believe what people are really complaining about is that the feedback loop is too slow. The more agile an Expert Group can be, the more people will feel heard and the more continuous the conversation and progress will be.
The worst thing an Expert Group can do is go dark. The more agile we are, the more we stay in the light.
"" In what ways do you focus on operating in a transparent and participatory way? ""
We make sure conversations and issues are public from day #1. As soon as a conversation takes place about a spec, there are two paths it can take. It can take the dark path by remaining a private conversation or it can take the light path by opening up the discussion as soon as it materializes (there’s no harm in brainstorming in a personal conversation…after all, we have to think). The light path also benefits from the fact that it’s in writing and thus self-documenting. It’s hard to emerge from the dark path because context is always lost.
The more rigorous the Expert Group is about making conversations public and documented, the more transparent the JSR will be. Fellow members need to encourage each other to make points by writing them down in a public space.
We want to avoid comments like this at all costs: "working behind closed doors is actually a more comfortable mode of operation". No, no, no.
Since sharing information via e-mail is easy, that’s why public mailinglists are often the best way to go. Personally, I prefer issue trackers over mailinglists for serious discussions. The reason is, an issue has a state that can be tracked over time and ultimately concluded. A lot of times, discussion on a mailinglist can spiral out of control with no clear action.
"" In general, what are you and your Expert Group doing to enhance flexibility and agility? ""
The key to being flexible is simply keeping an open mind. New tools will come along, like GitHub. It’s important for the Expert Group to not feel like they have to be stuck in their ways and be open to experimentation. GitHub is profound because it changed the way software engineers work around the globe, and also brought that globe closer together. If an Expert Group refused, out of principle or habit, to try GitHub, then it could jeopardize a tremendous amount of progress. Obviously, change has to be tempered, because it does cause disruption, but when the solution has been tried, tested and accepted by early adopters, an Expert Group has to recognize that this is the time to be flexible.
Expanding on the topic of agility, I think GitHub (and git in general), has been a tremendous catalyst for agility. It gives the Expert Group the ability to work collaboratively with minimal overhead in a shared space, yet still have powerful tools for tracking contributions through the integrated issue tracker, pull requests and forks. One of the Expert Group members can work in a fork on an idea, share it with others, then submit it as a pull request once the idea is formed enough to reach the minimum requirements of a proposal. It’s this workflow that is going to massively increase participation and feedback and keep the JSRs moving along throughout the platform release cycle.
"" How do you encourage community participation and feedback into your JSR? ""
First and foremost, we encourage community participation and feedback by working publicly. I feel strongly that as soon as the community feels like they are being excluded, they tune out. To keep them engaged, we work publicly.
We also promote the progress using social media such as Twitter. It’s important to give the community a cue as to when we are looking for participation in or feedback on something specific. Like all of us, community members are busy, so they can’t always be watching. These little "wake up calls" give them a chance to chime in on significant measures without having to allocate too much of their busy schedule. The more specific we can be about the input we’re requesting, the more likely we’re going to get it.
Since git and GitHub is asynchronous, the community also has the freedom to chime in whenever it is most convenient for them. Participation and feedback can vary. It ranges from an issue report in the issue tracker, to a pull request with a prototype of an API change or simply a post to the mailinglist. We must give the community the space to be creative as well.
"" How do you monitor and handle contributors who stop delivering what they’ve promised, or who simply vanish? ""
The key here is to leverage the notification feature of the tools such as GitHub. For instance, if an issue has gone stale, we can simply "@" mention their username in a comment and they’ll get a notification. If they don’t respond, we can "@" mention someone else who might be interested so at least we can rekindle the conversation.
We’ve also used social media for this purpose. We can "@" mention their username on a social network like Twitter where it’s easier for them to respond. The important thing to find out is whether they still want to be involved. Once we know they do, we can ask them for specific actions. Having strong management skills here helps a ton.
"" What do you do to keep the project flexible in terms of schedule, market demands, public/community wishes for features, and so on? ""
I’ve found here that you need to be open-minded, but also firm. Community members will push boundaries. Sometimes, that demand is well-founded and is a sign that action needs to be taken. Other times, the demands are unreasonable. I’ve also found it pretty obvious how to distinguish between the two, but there is a whole Expert Group to consult if you aren’t sure.
Here’s what’s most important. Take action when the demands are reasonable and universal. Push back when they are unreasonable. But always be friendly (or think of it as professional). There’s absolute no room for mistreating someone, even if they have unreasonable demands.
"" One of the most challenging things that can happen to a JSR effort is to have uncooperative or inactive contributors. How did you keep up the work momentum in the spec development process? ""
The answer to this question may be the opposite of what you expect (and be prepared to think of it that way). The key to keeping people active and cooperative is to be aware of when you are overloading them. Most inactivity comes from burnout, not disinterest. If someone isn’t responding, find the one thing you’d have them do and clear everything else off that person’s plate by reallocating the work. You can really turn around someone’s participation by giving them a win. As they get back up to speed, they may take on some of their old work, or perhaps they simply want to pick up fresh tasks. Don’t burn people out.
I’ve talked a lot about communicating and this is an opportunity to address the issue of over communicating. The EG, especially the spec lead, needs to recognize when they are posting too much information. If you constantly hit the mailinglist with long dissertations, you are going to wear people out and quickly. There are times when you need to be through, but play those like a joker card. Try to be as concise and too the point as possible to respect the time and energy of the people participating. Doing so will go a long way towards preventing burnout.
"" Did you do anything specific to streamline your JSR’s discussion, writing, submission, review, and updating processes? ""
The GitHub workflow. In particular, see https://guides.github.com/introduction/flow/index.html
I cannot overstate how powerful and effective this simple workflow is. You will transform a community by making the barrier to contribution as low as humanly-possible, then lower. People have tons of ideas. The reason you don’t hear about a lot of them is because something is getting in the way of communication. Be ruthless about removing communicating obstacles. There may even be something better than GitHub, esp for spec changes (see prose.io for one idea).
"" How have you refined your communications with your EG, observers, and industry to move the process along more quickly and efficiently? ""
More GitHub.
"" How do you organize the workload in order to be able to post materials promptly throughout the life cycle of the JSR? ""
The key here is to leverage the powerful tools in the issue tracker. A simple way is to use milestones in JIRA or GitHub Issues. Another way is to use an agile board interface like JIRA agile or waffle.io. The agile board interface helps people visualize the flow of progress, and when tasks are falling behind.
Another key is automation. When it’s time to post materials, it should be a simple as pressing a button or running a script. Rarely do you see this done, but the impact is profound. We use a build tool (Maven) to handle some of this, but we could do better.
"" How do you perceive pressure from the industry to complete the JSR quickly? Does that pressure affect your progress? ""
Software moves a lot slower than people think it does. Our monkey brains (or our brains on Hacker News) see a year as a long time, but it really isn’t. I think it’s much more important to have steady progress than it is to move quickly.
And trust me, if we achieve steady progress, people will perceive that as quick because there’s always news to consume and decisions to make. Time flies when we’re having fun, but it also flies when we are busy making progress. The JCP should borrow the motto from Toyota, "Make progress every day."
"" How do the new JCP version 2.8 and 2.9 requirements help or impact your work as a JCP Specification Lead? ""
There’s no double about it, the new requirements help set expectations about openness. Expert Groups, such as the one in CDI, no longer have to waste time debating whether working transparently is a priority and what should be open. The members come into the group with an understanding that we’re going to work in the open and we can get down to business.
I want to put extra emphasis on the openness of the test suite. Testing is the engineering rigor of software development. If we can’t collaborate on the tests in the open, then we can’t collaborate effectively on software API development…and there will be many unforeseen bugs and oversights. It’s absolutely, positively imperative that tests suites are open.
"" Do you have any tips for beginning Spec Leads to encourage them to operate in a transparent manner? ""
Be inviting and make it clear where and how people can help. Every good README on GitHub has a "Contributing" section. Every JSR should have the same clause. If you want people involved, let them know how.
As for being transparent, just do it. If you are typing an e-mail to an individual or group of individuals, ask yourself way it can’t be posted to the list. If you receive an e-mail from an individual or group of individuals, ask them if you can forward it (or part of it) to the list. Go public early. Going public later is much, much harder.
Default to open. In fact, you should consider requiring a case to be made for justifying a private discussion. Without a clear case, you have to go public.
There are tons of great articles out there about how to work in the open. I recommend reading them and linking to them from your JSR. Help participants understand that this is the culture and help them understand how to be good citizens of it. Here are some examples:
"" Do you have any other ideas or processes that we should include in this case study that will help and inspire their spec leads to operate with more creativity, agility, and transparency? ""
I believe strongly that JSRs should embrace a lightweight markup language, such as AsciiDoc, for all formal documents such as the specification. Most, if not all, of the EG and community members are programmers. After all, we are developing APIs for a development platform. AsciiDoc allows you to treat content just like code. It’s written in plain text like code. It’s stored in revision control (git) like code. It’s modified (via patches and pull requests) like code. Best of all, it’s easy to read and edit in raw form.
AsciiDoc has transformed the way that the CDI specification has operated. No one is afraid to edit plain text content. They see the document for what it is, lines of statements. When one or more of those statements is wrong (or not to their liking), they just change it and make a request.
With AsciiDoc, it’s also possible to include source code easily. Better yet, the source code can be included from the test suite or API so that it’s accurate and verified. It’s also possible to embed references into the document to issues or tests to strengthen and/or reinforce the integrity of the content.
AsciiDoc was specifically designed to handle use cases like this. In short, it just makes sense to everyone involved…even if they’ve never heard of it. That’s because AsciiDoc follows the core principles of software development, DRY and agile.