Add newcomer label

Sean, the problem I see is with a weekly event like BMM is that if you A) miss the announcement, or B) miss the event, then you don't participate. If there were something like this newcomer tag, that facilitated diving in and helping right away, it could be extremely helpful. I think that, ideally, we should keep the bar for participation as low as possible.

I agree with Jason. "Quickfix" or something like that would probably be a better name for it (more descriptive), and there's no reason we can't have BMM as well.

I'm not sure about a new comer label. I almost wonder if we need something of an "old timer" label. Or some kind of beacon badge for people to go to for questions. For example if you are an established Community Dev since July 2011 people can see you and introduce themselves saying they would like to know where to go to get started if they want to join in coding.

There could also be a Community rep badge and that can be a person perhaps who has been elected, or maybe just a person who self-selects themselves to volunteer helping newHere's.

My only reservation about that, is how to make sure that isn't abusive in any way?

Still I think the general idea in the rough is not bad, just perhaps could warrant further elaboration and discussion?

MP: Please read the proposal description again. It's not a label for people, it's a label for tickets. From reading SleepyDaddy's comments in the votes, they didn't understand that, either.

That means that either this isn't a very well-written proposal, or people aren't taking the time to actually read what they're voting on. I think that it's also being overlooked, because it was posted in the main community forum, instead of one of the groups (where it may have gotten more attention).

@Brent: Well that's the thing. I don't care if people want to move fast on doing more coding. Do you see me objecting in any of my comments about working on the code base?

If I have objections, it is that no one is taking the time to define what the vision is. My requests for that are being either ignored, or misunderstood, or countered with just a little hostility that I do not understand. I'm taking the announcement for face value. But maybe I shouldn't.

I'm not understanding why there is resistance (fear?) to look at the big picture and see what the community (meaning, inclusive of people on the stream) wants. It is just expression, it is not a dictate.

I do not understand the need for controlling the speech of others by voting on what people can say in this forum and where they say it and how. I do understand having that sentiment in Github.

This misunderstanding in regard to this post is also because there is an assumption that this is more of the same, community of devs (coders) and no one else. IF they only want coders here then they have to stop using the word "community." Use development team or software collaborators. Stop using the word "community," because it isn't one.

What they don't understand, is that by not making a mission statement or requesting input from the outside, just to talk about it (!!!), they are only turning off people. There is a history of this.

What are they afraid of?

Please don't take my post as a rant. Though I suppose it might be seen that way.

@MP: The idea that anyone is "scared" is a misconception. Cautiously thinking about the most sensible decisions that everyone can agree upon is what we're going for. I think a good goal is to sort of have a "Majority-Vote Democracy" for now, while we try to figure out the infrastructure of people that needs to be put together. As time goes along, we can evolve into a better-defined "Democracy by Consensus".

Getting there takes time and planning, consulting people that have been involved in the project the most about what to do and how to do it. It's about fostering good discussions concerning immediate needs.

Right now, the momentum of the project depends almost entirely on coders. You can make the argument that the userbase is what should drive the momentum, and you'd be partially right, but without people diving in and polishing up the code in areas that badly need fixing, padding up a user community is not very useful. You can have all the users in the world touting it, but that really doesn't drive development much.

With that in mind, I think it's important that we pay attention to the developers we've had in the community for a long time, and address their needs that have gone unanswered for a long time. As Johnne put succinctly, he took a break from contributing to D* because he felt like he was a workhorse with no say in the direction of the project.

Let's take a moment to be honest with ourselves: a month ago, we weren't even using this tool. There was no place for any sort of output, and the project was sitting at a standstill. For the past two years, there were about four people making the core decisions of where the project was headed.

Now, we're about 47 users in on this tool. We are discussing ways to nurse the project back to health, and the best way to move forward.

Opening up the floodgates to every Tom, Dick, and Harry on the stream doesn't resolve any issues that we have right now. Right now is about serving immediate needs of the project, and those needs are infrastructure (both technical and governance), policies, and technical platform decisions. This problem is two-fold because we could also risk choking up this server with too many users. The Loom.io people are working on building the system to scale, but it's going to take some time.

I think the people whose immediate needs must be served are our developer community at the moment. In that regard, the term "community" is correct: it's the community of people that actually work on the software in some way, shape, or form. They're the people doing all the work right now, and they need to be given a voice to express their needs and concerns. They understand the technical implications behind what they're working on.

I also think you're jumping the gun on the "controlling speech" angle. What can you not say or express now that you could before? I just think it's disruptive to have a bunch of people spin off a ton of groups without voting on it first. It promotes bad infrastructure practices.

It's not like it's that hard to say "I think we should have a group about this particular set of topics", have people vote on whether they think we really need it. That's not censorship. I mean really, you're even free to go make a proposal to change an existing policy if you really don't like it. That's democracy.

Back on topic: what Johnne meant was having easy low-hanging-fruit bug labels that newcomers could fix easily. Technically, we already have Quickfix, but I can agree that Quickfix is kind of a vague term that has been applied to lots of different issues that might not be newcomer friendly. Just because you can fix something quickly doesn't mean it's easy, after all.

If we decide to present the proverbial 'low hanging fruit' with a new github issue label, I think we should also provide some fool-proof 'first steps' on how to get started on each of those issues.
Kinda like we had with the bugmash items, but maybe even more detailed, possibly even with a 'tutor' interested devs can contact and who would be willing to guide them through the process.

That's actually a really good idea. It kind of reminds me somewhat of how the FreeBSD community does mentoring. Worth checking out: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/port-mentor-guidelines/

Brent, you wrote "That means that either this isn't a very well-written proposal", that is true but not only that, this proposal should be in the Developer proposal subgroup, IMO.