Using labels to sort issues by theme

[Matthieu Rigal]

Hi guys,

I've just started to do it with the Aggregation Framework and I wanted to propose it to you before doing it. I think it would make sense to add thematic labels, so that if one wants to tackle one of our big pain points, it could easily find all the tickets related to the topic. Just linking them in comments doesn't sound like a good solution for me as long as we have so many open issues.

I would then propose to create some others, with the same light yellow color, as these labels are here for filtering, not for visual impact, like:

- Connection

- ListField

- EmbeddedDoc

Just to be able to get at once our "big blocks of problematic code areas".

For example, with the aggregation framework, just looking at the 5 labelled issues, once has already a bunch of ideas what to do and where to work at.

Best,

Matthieu

[Matthew Ellison]

I think adding labels for 'components' is fine if it is found to be useful.

More importantly, I think we need to be looking at adding labels for severity and priority of incoming issues. This way when a new issues comes in one of us can triage it with a severity and priority (and component as you mentioned) which will help us in deciding exactly what we want to complete for upcoming releases by sorting the labels. 

--

---
You received this message because you are subscribed to the Google Groups "MongoEngine Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongoengine-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthieu Rigal]

I think that for priority we should use again milestones better. Severity might be handled by labels.

But to use milestones, we should define a roadmap and how we see next versions coming in.

I think for example that the removal of django is really big change and therefore the next one should be a 0.10.0.

Then I think we still need a really big bunch of features before pretending having a 1.0

[Matthew Ellison]

I agree, there are some larger features before 1.0 and it would be nice to see the issue backlog mostly cleared as well before we think about release a 1.0. Currently there is so much in the backlog it is easy to get lost :) but we've been making great progress the past few days to start cleaning it up.

As for the labels.. I could see us using the milestone field as a priority however that only works if we continue to use a linear release model. With all the discussion around 0.9 and the "DoesNotExist" exception, I've been doing a lot of thinking lately as to the best approach for this project...

(1) We continue with the (mostly) linear model that MongoEngine has worked off of up until the point and better document upcoming changing features. This means all bug fixes go into the new version and are not fixed in a dot release of an old version. 

(2) We use a release branching model which allows us to fix bugs in the version they are found, release a dot release of that release branch (0.9 -> 0.9.1) and then merge the fix into the upstream releases (0.10). In-house we use this for our larger projects where our customers (users) are unwilling to upgrade to a new major version in a short period of time but yet still need bug and security fixes.

It's amusing how all these questions and discussions are all interconnected.  It's good to have these sort of discussions about the general direction of the project as it moves forward. :)

[Matthieu Rigal]

And I am happy to have you as a co-maintainer to work on the whole structure :-)

You may be interested also by the Issue I have created about the wiki. It should have been discussed here, but it would between both of us and eventually Ross...

I had actually even thought about introducing something like the followings, but this would be really too much...

https://asana.com

https://trello.com

https://taiga.io

I think we are still too small for changing the release process. I also do really like the minor and major branch, also how Django makes it, but I think we could handle that when we are bigger, more mature and with more maintainers. For now, for simplicity, I would stick to proposal 1)

--

---
You received this message because you are subscribed to a topic in the Google Groups "MongoEngine Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mongoengine-dev/tkLCwexwjUc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mongoengine-d...@googlegroups.com.