Note: This discussion was imported from Loomio. Click here to view the original discussion.
Proposal: Add newcomer label
So BMM didn’t seem to really kick-off, how about a more general and less time consuming approach:
Everytime you see a ticket in the bugtracker that’s quite easily solved but you’re too bored to do it or it’s too time consuming for you add the label “newcomer” (or so). And maybe add an comment pointing to the entry point that needs fixing for this bug.
We could then point people who want to start contributing to this tag.
Outcome: N/A
Votes:
- Yes: 3
- Abstain: 5
- No: 2
- Block: 0
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
I think we should still give BMM another shot. It’s worked out pretty well in the past; I just think that tags have a much lower exposure rate for new users than some announced weekly thing.
stupid me is wondering what BMM means?? pls get me on track
BMM=Bug Mash Monday (devblog.joindiaspora.com)
also, we have a similar label on github, “quickfix” that I think would practically cover the same issues.
I like quickfix better than newcomer. Or “bitesize” which I think is even better, Ubuntu uses this term for easy little bugs.
I don’t think this conflicts with BMM, both can be used. BMM can be used to draw attention to small bugs whatever they are called - but they should still be tagged as small.
SleepyDaddySoftware - #newhere is separate, this is about labeling bugs for newcomer devs 
I think that we should have a good way for new people to dive right in and start helping.
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.
@Sean: You miss the point completely.
Also when you interpret what I am saying, you have the consistent habit of misplacing it in huge, exaggerated terms. It’s not really right. People see this and it creates distrust.
I never said that I was for getting in the way of the coders. But somehow this has been construed this way. I wonder why?
Majority rule is not what you want, believe me. There is just a small group who wants control. We can argue the merits or demerits of control. I’d rather not. I’m for an open society of people talking about the community of Diaspora, one that is inclusive. You are not. You want to control how people use this tool, even.
Even Richard of Loom,io mentioned not to use this tool as a way to run a majority-rule democracy. You have deemed this so. I am not sure where your authority comes from. But it’s fine. You are going to do what you will do. Don’t think I will get in your way.
There are plenty of people who feel as I do. You just can’t see that yet, because you don’t want to give space to that discourse.
I know it is a waste of time to post this, and I am also cross-posting. But you might consider why I am cross posting. It is not because I’m rude, lack intelligence, or that I desire control.
@MP: I don’t desire control. I, like everyone else here, desire structure, which requires rules to be followed. Common sense dictates that. You really can’t have a working community without it. If you’d like to make the argument that you can, I recommend you go look at all the wonderful progress that the GNU/HURD project hasn’t made.
The majority vote system is one in which many of the developers here have agreed is a good temporary system for now. It is not intended to be used that way for the long-term. Indeed, something better will need to be proposed in the future. I just consulted Richard about this last night over Skype, as a matter of fact.
We could continue to argue, but it’s only going to keep going in circles at this point. I’ve explained how we can use this tool together to set up some policies to work together better. I’ve explained that we need not flood this with people with reckless abandon. I’ve explained that developers are the focus now, because they’re the ones doing all the work at the moment.
You have a space to express yourself, and there’s nothing stopping you from creating discourse in the Diaspora Community main group.