First impressions on documentation about new feature system / informal votes

Was poking around following links from the new feature process page to the new feature GitHub repo and the below two excerpts were confusing for me at first read:

Django contributing docs section for How we make decisions:

Occasionally, discussions on feature ideas or the direction of Django may take place on the Django Forum. These discussions may include informal votes, which follow the voting style invented by Apache and used on Python itself, where votes are given as +1, +0, -0, or -1. Roughly translated, these votes mean:

  • +1: “I love the idea and I’m strongly committed to it.”
  • +0: “Sounds OK to me.”
  • -0: “I’m not thrilled, but I won’t stand in the way.”
  • -1: “I strongly disagree and would be very unhappy to see the idea turn into reality.”

Although these votes are informal, they’ll be taken very seriously. After a suitable voting period, if an obvious consensus arises we’ll follow the votes.

GitHub django/new-feature README:

Please avoid doing the following:

  • Writing comments that are “+1” or “-1”. Use emojis to share those opinions, please.

After reading more carefully, they’re not contradictory: I missed the key phrase “may take place on the Django Forum” in the first excerpt.

Missing that one phrase though meant that I did a bit of a double take when I went directly from read the django docs explaining new features that included definitions for how django uses +1, -1, etc. to clicking through to the new feature repo where it explicitly said not to use the +1/-1 system that I just learned about in the django docs.

The mistake was on me for not thoroughly reading the first docs though, so I guess I’m not sure if it’d really be all that helpful to suggest anything be done since the docs are do include the information. My initial thought for a potential suggestion had been adding “The +1/-1 system is only used sparingly for informal voting in the Django Forum when it could be beneficial to discussions” to the bullet in second excerpt above.

Now that I’m on the topic and thinking about this more though, a related thought is why have two separate systems (they don’t look at face value that different to me)? Like, my thinking is don’t they map like this:

  • +1: “I love the idea and I’m strongly committed to it.” / :tada:: This feature seems like a straightforward and beneficial addition
  • +0: “Sounds OK to me.” / :+1:: I support this feature and would use it
  • -0: “I’m not thrilled, but I won’t stand in the way.” / :confused:: I have no strong opinion on this feature
  • -1: “I strongly disagree and would be very unhappy to see the idea turn into reality.” / :-1:: I oppose this feature or believe it would cause issues for me or Django

Okay, actually trying to map them like I did above and reading the definitions side by side does seem to clarify the distinction: here’s an attempt #2 for mapping, which I think is more accurate to what is intended:

  • :tada: = +1
  • :+1: = [a nonexistent +0.5]
  • :confused: = -0/+0 [lumped together]
  • :-1: = -1

I already wrote it so I’ll keep the above thoughts here as is just in case it’s helpful / if anyone was curious about first impressions from someone who was reading this but is not even remotely as in the weeds as a lot of others in the community. I had to really stop and think about this for the distinction to be clear, and my first impression was that it looked a little bit like an overcomplication to have two systems saying basically the same thing.

To summarize more clearly: my initial impression was that it made sense to me logistically why we’d want to use emojis instead of text in github (so there’s auto-tallying), but it didn’t make sense to me why there was a distinction (as opposed to a mapping) between emoji vs +1/-1 system.

2 Likes

Thanks for posting @StephanieAG. I’ve too have noticed that the emoji system on the new-features repo is missing the weaker negative signal, despite the grumpy face implying that.

Watching the repo, I think it’s probably OK, because (whilst it leans positive by missing this option) there are still many steps beyond just the initial count the reactions, which is at best a guide.

But that’s just my half-take so-far, so please don’t read it as Official™ :grinning_face:

I think reviewing here would be worthwhile.

§

Whilst we’re at that, I was on the repo the other day, and I think we need to be able to close ideas at least as “Not Now (can be reopened if needed)” in order to keep it readable.

(Massive distraction from topic. Sorry)

1 Like

Thank you for raising this. I think there’s some tweaking we can make.

I think my interpretation is a bit different. The :tada: isn’t on the preference scale, it’s an indication of simplicity to implement. Someone could say, this is easy, but I think it’d be bad for Django where they use :tada::-1:.

I think this would be beneficial. Especially if it clarifies that during long discussions, it can be difficult to determine the strength of one’s opinion about the idea as a whole. Using the number value, helps clarify if arguments are blockers or not.