To Commit or Not to Commit

Introduction

This essay was written by me, Brandon Nolet, in the context that some projects may have a lot of end-users, but very little feedback/involvement in the developer facing community.

An Active User

An active user, in the context of software development, is a user that contributes issues whenever there is one that’s noticed, gives feedback on liked features/implementations of features and disliked features/implementations of a feature, and generally participates in certain calls to action regarding the software project.

Issues are filed with a thorough description of what the problem is, what the desired outcome is, and possibly some general direction as to where the problem might be stemming from. Upon filing the issue, any questions asked by the development team are answered completely and in a timely manner as to effect the most efficient reparations of issues.

Feedback on given features/feature implementations is pointed and not littered with emotional jargon such as “I really hate this” or “this is stupid.” Feedback is not nitpicky either and focuses on general direction of features/implementations rather than bikeshedding.

Calls to action are followed in a mature manner and is not spamming social media with a project’s message. Rather the following of a call to action can be seen as a genuine message to a person’s given following (whether online or offline). The message coming from this user seems to be coming from personal experience rather than just a canned phrase that was not at all thought out.

A “User from Outside”

A user from outside the community, in the context of software development, is one that either doesn’t contribute issues at all or does so in a half-ass manner. Feedback is usually littered with spelling mistakes, emotional jargon, and probably even incomplete to the point of being unhelpful. Participation in calls to action are also half-assed and most likely to be counterproductive.

Issues contributed, that are littered with spelling mistakes, usually come from an emotional point of view (“This made me angry, it needs to be fixed”) and generally detracts from the development environment. Dealing with these uses in discussion on the issue results in the developers having to pull teeth just to get the right information to actually fix whatever issue is being reported.

Feedback given causes the development team pause just because they’re contemplating whether they should even engage with this individual. With all the emotional jargon in the message it’s hard to figure out what they’re even mad about. Are they just having a bad day? Is there something to actually consider here? Oh, they don’t like that we use a volume slider instead of up and down arrows with a text box?

Calls to action probably result in less people wanting to use the software. Because it the message received sounds so canned and was sent to the person over and over again, they don’t even want to listen to what this user has to say. Why would they want to be part of a community with people like that?

Conclusion

Be an active user, don’t be a stranger. Come on into the inner circle. Contribute proper issues and give clear and concise feedback. It’s much better for you, and the developer, if you’re not emotional about the feedback you give.

Being the second type of person not only frustrates the developers, but also frustrates other users too.