Adding Priority label

[MuhammadMuradG]

It’s a good idea to help contributors to a project by directing them to issues that have the highest priority for the project. I assume these would be issues that are more important to the overall goals of the project.

I suggest adding label/labels for sort issues depending on their priorities to the core team.

[freakboy3742]

I understand the underlying idea here; however I'm not sure issue tagging is the right approach. Open source projects aren't quite the same as "traditional" engineering projects, because the workforce are (primarily) volunteers; as a result, the relationship of "work delegation" is very different.

There's three details in particular that make tagging issues as "high priority" tagging problematic.

Firstly - if a bug truly is a high priority - e.g., a crash in a recently added feature - we're probably not going to wait for a volunteer contributor. The core team will fix the issue before a volunteer even gets to it.

Secondly, we need to able to differentiate between "a high priority for the core team" and "a high priority for the project". The core team doesn't need the direction of tagging, as we can just work on the things that are a high priority for us. From the perspective of the project, the highest priority items are whatever the community wants. Speaking personally, I don't have a huge need for (say) pop-up notifications. However, if someone in the community particularly needs them, they can contribute a design and implementation (and, if you've been tracking the ticket tracker... someone has).

If the core team flagged a specific set of items as "high priority", it might give the impression that we're not interested in other topics - which wouldn't be accurate, and could be counterproductive. The core team needs to take whatever effort is volunteered; unless a proposal is hugely off topic for the project, or premature for some architectural reason that might not be obvious, it's unlikely that the core team will ignore an offer of volunteered effort.

Lastly, many of the places where there is work to be done don't fit nicely into a ticket structure - or, if we were to open tickets, would result in dozens of mostly placeholder tickets. One "meta" issue like this is widget coverage. For example, there isn't currently an implementation of ActivityIndicator on Windows, iOS, Android or Web. We could open 4 tickets for these 4 missing features; or 1 ticket for "Implement Activity Indicator" tagged with those 4 missing platforms, or 1 "Implement missing widgets" ticket, flagging that Activity indicator has some missing platforms. If we were to do this for all the widgets that have missing or incomplete implementations, we'd open dozens of tickets... and it's not clear that it would actually help us direct effort where it is needed. There's not much more to say other than "This gap in the supported widget chart? Fill it in".

Stepping back, I'm guessing the underlying issue you're trying to address here is the "what should I work on?" question that faces any new contributor. To address this, we've done two things:

1. We've flagged a bunch of issues as good first issues. These are issues where there are tickets, which the core team has identified as being approachable as a first time contributor to the codebase. This can be evaluated in a much more objective fashion than "what feature is a high priority"; these are usually bugs, and there's a clear(ish) path to a fix, but the issue isn't pressing enough that the core team has fixed it already.
2. We've included a what should I do section in the contribution docs. This provides a way for us to describe the "meta" issues without needing to open explicit tickets.

That said - we're always on the lookout for ways to smooth the onboarding path for new contributors, so if you've got ideas for how we can better coordinate volunteer efforts (including, potentially, an impassioned argument for why I'm wrong about high priority ticket tagging :-) ), I'd definitely like to hear them.

[MuhammadMuradG]

This makes sense for me. Actually, I suggest this because I found some contributors spend a lot of efforts in features that may require critical changes in some part of the project, which may requires a lot of efforts. The contributors often have limited time and I think directing them to things that may produce a useful work is better than obsolete opened PRs.

[freakboy3742]

Sure - I can understand that. However Toga is sufficiently "new" as a project that any contribution is almost certainly a worthwhile one; if someone is motivated to build a non-trivial feature, it's almost certainly worth our effort to review that contribution. And, if that feature is easy enough to explain, but requires major changes to the project, then that probably indicates that we've got something fundamentally wrong in our design, and it's better that we fix those problems now, rather than discover them after we hit v1.0 :-)

[MuhammadMuradG]

Great to hear that! This makes sense.