Could you provide a description for that tag (preferably with an explanation understandable by 'outsiders', like me) and a proposed name?

(I'm curious why someone would call that a "spike" but maybe there is a Wikipedia link available which covers that? :P )

@Aklapper Thanks, I've updated the description.

Looking at the description (and being not native English speaker like perhaps majority of users), I would rather suggest widely more understandable "Research" or something like that. (Such keyword is actually already being used in task titles to "tag" them.) Other possible similar words used here: Investigation, Evaluation.

@Danny_B Thanks for your feedback. "Spike" is the terminology widely used by teams working with Agile, at the Foundation or otherwise. It is an industry-standard term. My concern with an overbroad term is that it will lead to overbroad use.

@MBinder_WMF :-) My concern was quite opposite - the term is known/used pretty much within agile only. That means you won't likely get others to use it since they wouldn't know what it means therefore you would have to do such tagging yourself / yourselves (teams using that).

Also please bear in mind, that the word "spike" is being used typically by ops for tasks about ie. momentarily high load, long latency, memory consumption etc...

Some statistics:

ATM there is
~330 tasks having "spike" in their title, of which for the first sight (no deep analysis) approximately quarter is related to the ops issues such as mentioned above.
~320 tasks using "research" in their title, of which some (~10) also use "spike", such as T126367: Provide data on top pageviews across all projects daily or T123377: [Spike] Research the correct API calls to use for managing Gather collections for saved pages..
~640 tasks using "investigate" in their title, of which some (~50) also use "spike", such as T137679: [Spike] [2 hrs] investigate using Universal language selector (ULS) on mobile web.
~80 tasks using "investigation" in their title.
~160 tasks using "evaluate" in their title, of which 1 also uses "spike" T126100: Spike: Evaluate whether AJAX page load is viable over slow connections.
~160 tasks using "evaluation" in their title.
~40 tasks using "find out" in their title, of which 2 also use "spike", such as T134782: Get health check warnings when a web node goes down from the load balancer's perspective.
~110 tasks using "investigate" in their title, of which some (~15) also use "spike", such as T136876: [Spike] Explore testing i18n messages.

Of course the numbers above contain some false positives when given words are used in different context, but on the quick look it's definitely not more than 10 %.

According to these numbers I would highly encourage to use "Investigation".

@Danny_B Thanks for the data. :)

I think "Research Spike" would be a good compromise between terminology and language. Alternatively, the teams could be specific with their titling ("iOS-Spike" or "Android-Spike"). The thought was to make it more generic since so many teams use the term the same way that it seemed redundant to have multiple tags.

CC @Fjalapeno who suggested the idea.

This is how I have seen it referred to in the past on other engineering teams: "Research Spike"

In T138380#2421692, @MBinder_WMF wrote:

@Danny_B Thanks for the data. :)

I think "Research Spike" would be a good compromise between terminology and language. Alternatively, the teams could be specific with their titling ("iOS-Spike" or "Android-Spike"). The thought was to make it more generic since so many teams use the term the same way that it seemed redundant to have multiple tags.

Specific tags (in general any kind of more-than-one-criteria tag) are not the best idea. You can always do interjection of ie. spike × ios. Definitely generic. That's why it is tag, otherwise it could be column on the workboard of such projects (or even milestone if it would need further breakdown).

While I am always into compromises to satisfy as many participants as possible, I would encourage to find single-word tag, which is more practical and easier to remember.

Please also mind, that we can have aliases, so the only deal is which term will be defaultly visible as the tag. And there I would suggest something broadly used.

Being a native english speaker and steeped in the software development world for a long long time, please take my comment with a grain of biased salt ;)

"agile", "scrum", "sprint", "epic", etc don't make intuitive sense (even to native english speakers), but we use the terms widely and indeed even have corresponding tags in Phabricator. From my perspective, bikeshedding for over a week about creating a "spike" tag seems wasteful (to borrow some Lean terminology). My preference would be to just make the 'spike' tag and make sure it's defined somewhere discoverable (it is already defined in the TPG glossary, though I'm not sure that counts as 'discoverable').

I think one of the many cool things about being part of an open source software project is the fact that you get exposed to lots of things you may not have known previously, particularly terminology and practices. The knowledge of which you can bring along with you to the next project/job/gig/etc. So, I believe there is a lot of value in maintaining standard terminology - not just for us internally, but for volunteers, etc who might not otherwise get exposed to it.

In T138380#2421771, @Awjrichards wrote:

"agile", "scrum", "sprint", "epic", etc don't make intuitive sense (even to native english speakers), but we use the terms widely and indeed even have corresponding tags in Phabricator.

Not for everything though (yet). We had some discussions at Wikimania about some improvements though.

From my perspective, bikeshedding for over a week about creating a "spike" tag seems wasteful (to borrow some Lean terminology).

For the record: I came in here some 18 hours ago... ;-)

My preference would be to just make the 'spike' tag and make sure it's defined somewhere discoverable (it is already defined in the TPG glossary, though I'm not sure that counts as 'discoverable').

Well, until now it did not count for me ;-) And I was looking for some our glossary because of other things already some time ago. Thanks for pointing the link out. I'll check the possibilities how to make it more discoverable.

I think one of the many cool things about being part of an open source software project is the fact that you get exposed to lots of things you may not have known previously, particularly terminology and practices. The knowledge of which you can bring along with you to the next project/job/gig/etc. So, I believe there is a lot of value in maintaining standard terminology - not just for us internally, but for volunteers, etc who might not otherwise get exposed to it.

Good point. While I am more or less familiar with Agile/Scrum terminology, I was rather speaking up on behalf of BFUs (no offense intended) and pointing out that such tagging will then remain on teams resp. their members rather than on bug reporters from outside.

From my perspective, bikeshedding for over a week about creating a "spike" tag seems wasteful (to borrow some Lean terminology). My preference would be to just make the 'spike' tag and make sure it's defined somewhere discoverable (it is already defined in the TPG glossary, though I'm not sure that counts as 'discoverable').

While this would be my preference, too, the nature of Phabricator and how it is used within the movement means that requests like this need to be posted and waited on, so that folks (like Danny_B) can have time to discover it and weigh in (and Project Admins can enforce the uniformity of Phab projects, which can quickly degenerate without guidance).

While I am more or less familiar with Agile/Scrum terminology, I was rather speaking up on behalf of BFUs (no offense intended) and pointing out that such tagging will then remain on teams resp. their members rather than on bug reporters from outside.

I recognize that bug reporters would be disadvantaged by unknown terminology if they are not part of the teams using the terms. However, in this case, spikes will almost always be identified by the teams. The bugs and feature requests can still come from outside, and the spikes will be made in response.

IDK if @Aklapper is off now for a bit, so let's say if he won't speak up (and potentially create it) until Sunday evening (we're the same timezone), I'll create #Spike. In the worst case we still can rename it and/or use aliases...

@Danny_B Sounds good. I can also create the tag (I just wanted folks to weigh in first, per protocol) :)

In T138380#2421900, @MBinder_WMF wrote:

@Danny_B Sounds good. I can also create the tag (I just wanted folks to weigh in first, per protocol) :)

...which honors you , since it is becoming less frequent and stuff is being created without previous discussion...

Frivolous comment: I have always (or at least, for my last two work tracking systems) wanted spikes to have an icon derived from https://en.wikipedia.org/wiki/File:Spike_(Buffyverse_character).jpg. Of course this would make them even more jargony, so this idea should be ignored.

Actually, is this tag supposed to be used only within projects/teams using agile or everywhere? If the latter, then that would be again another reason for more generic word...

Please elaborate the description to not only describe what given name means but also what types of tasks are supposed to be marked with it and which tasks not.

Thank you.

I came here to support Spike, but after some research, I have changed my mind. I disagree with the definition currently in the TPG glossary, and a quick web search revealed a few other definitions I disagree with (along with several that I do agree with). I'm afraid spike does not have the level of shared understanding that I had expected.

As a result, I now favor Spike, with Spike as an alias. However, I would be OK with Spike if that is the consensus.

In T138380#2422299, @ksmith wrote:

I came here to support Spike, but after some research, I have changed my mind. I disagree with the definition currently in the TPG glossary, and a quick web search revealed a few other definitions I disagree with (along with several that I do agree with). I'm afraid spike does not have the level of shared understanding that I had expected.

As a result, I now favor Spike, with Spike as an alias. However, I would be OK with Spike if that is the consensus.

I've googled a bit before as well (aside from Phabricator datamining as shown in T138380#2421543) and came into the same conclusion, hence why I made suggestions here. But being not an agile/scrum pro, I did not want to push so hard, so thanks for speak up.

Spike with Spike as an alias is my favourite combination after all research and comments here as well.

Spike with Spike as an alias is my favourite combination after all research and comments here as well.

@Danny_B I'm unfamiliar with aliases. Is that a Phab-specific feature?

Actually, is this tag supposed to be used only within projects/teams using agile or everywhere? If the latter, then that would be again another reason for more generic word...

The teams I know that are asking for it are employing Agile methodologies. The idea behind making the tag non-team-specific is about avoiding redundancy across those teams, as we discussed earlier, with the added benefit that any team could also use the tag.

However, there is a risk that teams who use the term differently would also make use of this tag (this is already happening with some tags, like Epic ). However, since the primary purpose of this tag is to make filtering and high-level visibility easier (and streamline existing processes, such as prefixing "[Spike]" in titles), I don't have a problem with this risk, myself.

In T138380#2422479, @MBinder_WMF wrote:

Spike with Spike as an alias is my favourite combination after all research and comments here as well.

@Danny_B I'm unfamiliar with aliases. Is that a Phab-specific feature?

In a nutshell:
You start to type "#spi" and it will suggest you #investigation, because #spike would be its alias.
In other words:
One project/tag can have several names, however the only one (primary) is displayed.

Actually, is this tag supposed to be used only within projects/teams using agile or everywhere? If the latter, then that would be again another reason for more generic word...

The teams I know that are asking for it are employing Agile methodologies. The idea behind making the tag non-team-specific is about avoiding redundancy across those teams, as we discussed earlier, with the added benefit that any team could also use the tag.

However, there is a risk that teams who use the term differently would also make use of this tag (this is already happening with some tags, like Epic ). However, since the primary purpose of this tag is to make filtering and high-level visibility easier (and streamline existing processes, such as prefixing "[Spike]" in titles), I don't have a problem with this risk, myself.

If there is such risk, then generic word is better so it would prevent confusion. Specific word may create confusion (such as spikes in ops area as I've described earlier)

You start to type "#spi" and it will suggest you Spike, because Spike would be its alias.

That might work. The overhead for teams, then, would be just to know what "Investigation" means when they look at a task at at glance. I wouldn't care for it myself, but that's simply my own Agile-oriented bias and one I can't fully explain. :)

If there is such risk, then generic word is better so it would prevent confusion. Specific word may create confusion (such as spikes in ops area as I've described earlier)

Agreed, though in a perfect world there would be more judicious use of examples like Epic or Tracking-Neverending .

Phab is full of specialized agile terminology (Epic, "story points", etc) though I suppose other stuff exists may apply. The reason I like and embraced "spike" is because it is so specific and jargon-y (jargon excludes newcomers, but it also reduces ambiguity and is part of building culture, IMO).

Despite ~10yrs in agile software related jobs, I had actually never heard spike before coming to the WMF. (Similarlly with bikeshedding, actually.) But I like the specific meaning my team has for it, and thought its use was commonly understood (as @MBinder_WMF defined it) in wiki development, at least among the teams I work with most.

Investigation and research, with their broader semantics would be more confusing to us in the use we actually have for the tag (find and track this kind of work within our team's board(s)). An alias is okay I guess, but since no one has to use the tag, and its already a term in use at WMF (if not as widely as I thought) I feel like "spike" should be the label.

Also that allows us to put @JAufrecht excellent suggestion into effect.

The bureaucracy here continues to baffle and annoy me:
https://m.mediawiki.org/wiki/Talk:Phabricator/Creating_and_renaming_projects
Why is it so hard to create such an obvious tag?

(and sorry for the potentially disruptive tone but I feel like I'm in an echo chamber when I moan about this). It is my opinion you should create a spike tag and if it used consider that a success.

I think this has been a useful conversation. Why create a tag without discussion, if it turns out that a different tag would be substantially better? (Where "better" might mean less confusing, or useful to more teams, for example.)

Having said that, I don't want to still be having this conversation a week from now. At some point (soon), interested people will have shared their opinions and had the debate. Someone will have to determine which arguments have merit, and then make a decision.

In T138380#2423017, @ksmith wrote:

I think this has been a useful conversation. Why create a tag without discussion, if it turns out that a different tag would be substantially better? (Where "better" might mean less confusing, or useful to more teams, for example.)

If on the 22nd June a "spike" tag had been created in Phabricator instead of starting this topic and then today someone created a "Research Spike" tag what would be the damage one month on? At the moment, a week after the original proposal, no one is using either. I'd argue the damage of this to be far greater.

I don't find a spike tag necessary just because I don't really have a reason to filter by spikes at the moment, so the only change for me would be "[Spike]" in the task title moving to a tag.

That being said, I obviously don't have a problem with one being made, so if others will find it useful, then by all means go ahead.

I'm also with @Jdlrobson on this. Seems like over-engineering on process.

"Alias" = "Optional hashtags".

In T138380#2422840, @Jdlrobson wrote:

The bureaucracy here continues to baffle and annoy me

Off-topic in this task. -> T139210.

iOS would like a tag with which they can identify research spikes.

What is the purpose of identifying research spikes? How is the information used? We don't differentiate bugs from features as far as I know. Why create this tag then?

In T138380#2425465, @bmansurov wrote:

We don't differentiate bugs from features as far as I know. Why create this tag then?

For the record: This is partial true. We have OKR-Work vs. Essential-Work - although they are not originally intended for bug reporters to differ between bug report and feature request (and are not heavily used at all, except for one batch add by Nemo), they are sometimes being used for this purposes, since they significantly overlap with possible #bug-report and #feature-request.

@Aklapper Thanks for the links.

@Jdlrobson If the tag was being made for a specific team, it would only take a day or two (something like iOS-app-Bugs ). I recognized an opportunity for a global tag to mitigate redundancy, and with that comes a little more initial overhead. Thanks for your feedback and patience. I'm sure there will be more conversation in T139210: Abandon (or at least strongly simplify) project creation policy.

@bmansurov Some teams do differentiate between bugs and features. Regardless, tag is another way for teams to filter their boards, as well as maintain some consistency with how the cards look at a high-level. It's less lossy than prefixing titles, too.

@Danny_B After hearing the thoughts of the folks that will be using this tag, I'm still inclined to use "Spike", and define it as it is in this ticket. I recognize the value of the other sides in the debate we've had, but at the end of the day the primary users of this tag will be teams that know what a spike is, and the description will have a definition for those who need clarification. Unless there is significant disagreement by the end of the day tomorrow, I'll make the tag and we can put this to rest. Thanks for your help. :)

@MBinder_WMF For the sake of transparency, I would prefer, if the issue could be decided and action taken by someone uninvolved in the discussion. @Aklapper seems to be good candidate.

Also, since there is now discussion about weakening restrictions for tags creation, what should happen after the other similar tag will be created (and I am sure that it will happen)?

@Danny_B Sure. @Aklapper Would you do the honors?

Regarding

Also, since there is now discussion about weakening restrictions for tags creation, what should happen after the other similar tag will be created (and I am sure that it will happen)?

Is this in response to the hypothetical that @Jdlrobson suggested, where 2 overlapping tags might be created by accident? If so, I think it's best to keep that discussion at T139210: Abandon (or at least strongly simplify) project creation policy

In T138380#2427603, @MBinder_WMF wrote:

Is this in response to the hypothetical that @Jdlrobson suggested, where 2 overlapping tags might be created by accident? If so, I think it's best to keep that discussion at T139210: Abandon (or at least strongly simplify) project creation policy

If #spike will be created and restrictions will be weakened, I am nearly sure the #investigation or #research would be requested/created too...

I was trying to be also "forward compatible" with this possibility...

@Danny_B Ah, I see, thanks for clarifying.

I do understand that risk. Whether or not #spike has weakened restrictions, #investigation or #research may be created anyway. I don't think that's necessarily a bad thing (a task doesn't have to have only one or the other; it could, for instance, have both #research and #spike ). The difference is that #spike is being requested for immediate and defined use, equal across at least 3 teams, and #investigation or #research are theorized (if presumed inevitable). For at least the moment, the point is moot, and at the same time the teams are not getting a tag they have identified they need.

The reality is, if the teams requesting #spike don't receive it, they'll probably default to individualized tags, such as #iOS-app-spikes (a la iOS-app-Bugs ) just so that they can continue to work in their own process and language. Ideally, that potential redundancy doesn't happen, but if the global tag isn't possible for the reasons debated in this thread, so be it.

In T138380#2427741, @MBinder_WMF wrote:

@Danny_B Ah, I see, thanks for clarifying.

I do understand that risk

Can you explain this to me? If Research is created and adopted in parallel to Spike why is that a bad thing?

Misunderstanding... - The weakening I was talking about, was weakening of restrictive policy on projects/tags creating.

On the further details you have just provided recently, I have some more add-ons:

1. Why there can't be a workboard column "Spikes"? (In fact particularly almost none iOS project uses workboard, but most majority of them could be simply columns on one generic workboard.) Each iOS project can have such column.
2. If there is already iOS-app-Bugs then what are we actually discussing here? ;-) Simply create #ios-app-Spikes and that's it. The iOS-app-Bugs tag is also generic and I don't remember discussion about it like this - to have common #bug tag.
3. I might have missed it - which teams are those who need it apart from iOS, please? Thank you.

Why there can't be a workboard column "Spikes"? (In fact particularly almost none iOS project uses workboard, but most majority of them could be simply columns on one generic workboard.) Each iOS project can have such column.

If there is a column just for spikes, it will cause, among other things

• An inability to prioritize tasks relative to one another, since the tasks will be separated
• If on a sprintboard, an inability to move a card through a workflow without removing it from a "Spikes" column (thereby losing the categorization).

Regarding iOS, if each iOS project had a column for this, each project's board would have to be maintained. Those projects are not being employed as workboard, but simply as a way to filter the boards that the iOS team does actually use, such as Wikipedia-iOS-App-Backlog . One filter might be, say, iOS-app-feature-iPad .

If there is already iOS-app-Bugs then what are we actually discussing here? ;-) Simply create #ios-app-Spikes and that's it. The iOS-app-Bugs tag is also generic and I don't remember discussion about it like this - to have common #bug tag.

We're discussing the potential for a global tag, rather than a team-specific one, to avoid redundancy, and use, as you suggested in your example, something like a common #bug tag. At the moment, we have the benefit of hindsight, and should this request be successful, we may consider moving iOS-app-Bugs tasks into something more generic and befitting a global use-case.

I might have missed it - which teams are those who need it apart from iOS, please? Thank you.

Members of iOS requested the tag, and members of Android and Reading Web have seen sufficient benefits that they would also employ a global tag. It's my own presumption that, since there are many Agile teams at the Foundation, others can use it as an option as they see fit.

#sp

In T138380#2427743, @Jdlrobson wrote:

In T138380#2427741, @MBinder_WMF wrote:

@Danny_B Ah, I see, thanks for clarifying.

I do understand that risk

Can you explain this to me? If Research is created and adopted in parallel to Spike why is that a bad thing?

Being that said this exact way (just a pair of tags), perhaps nothing really serious.
However more (more or less overlapping) tags → less proper tagging / misuse of improper tags / not using of tags because of not knowing which → mess

Perfect being the enemy of good and oing through the conversation here, I'd say let's create #spike with an optional hashtag of #investigation (#investigation might never get used, but anyway).

Since I suggested this to the iOS team and to @MBinder_WMF - I'll quickly chime in:

I personally don't have any feelings on what the tag is called, only that it exists. As someone did above, there are lots of tickets with people using plain text in the title to identify a certain type of task. Clearly thats not a good idea.

Like @JMinor I never heard this term before I worked at the WMF - so I also thought it was a common term here. Which is why I believe @MBinder_WMF thought the tag would be useful for other groups in the org. If it isn't useful, then we can make an iOS specific tag.

Meta comment: I do think it is useful to discus topics on process, but like @Jdlrobson mentioned, there seems to a be a bit of bike shedding on what seems to be a minor topic. Whatever we decision we make, I would advocate wrapping this up quickly and maybe review this process in the future. It may be worthwhile to treat tags much like we treat some other content at Wikimedia, let users create what they need and let the community decide what tags are worthwhile by using them (or not using them).

Thanks, @Aklapper, and everyone else for their input. I've created the project Spike

I still think investigation would have been better (less ambiguous), but now that we have Spike, I DON'T think we should add # investigation as an alias [EDIT: Too late--it already got added]. I don't think anyone was arguing that we needed both--just that one would be better than the other.

Someone should communicate to all the opsen that Spike has nothing to do with traffic spikes. The tag description should probably also call that out explicitly.

@ksmith I think you meant "#investigation" (with `` to plain format). :)

Is opsen the ops team? Would you be open to communicating that to them?

I'll update the description.

All tasks having "spike" in their title were tagged with Spike.

@Danny_B I don't know if that's a good idea. Some tasks with "spike" in the title are not spikes in the Agile sense, as this thread has discussed. Did you account for tasks like, say, performance spikes (in the traffic sense)?

Do you really consider me that dumb? :-/ Remember it was me, who came with this issue and done the research... T138380#2421543

So yes, whatever seemed to be spike in ops terms, was ommitted.

Of course, if people put "spike" in title when it is not spike, it's their fault not mine and it's same like they would mark it with tag. (BTW: I've seen tasks created with "epic" in title, but story tag or vice versa, so obviously it's not 100% sure that I haven't tagged anyting which was not supposed to be. but I've done my best.)

In T138380#2431512, @Danny_B wrote:

Do you really consider me that dumb? :-/ Remember it was me, who came with this issue and done the research... T138380#2421543

To be fair, you said "All tasks", without qualifications. I didn't remember that it was you who did the research, so Max might not have either.

obviously it's not 100% sure that I haven't tagged anyting which was not supposed to be. but I've done my best.)

Ironically, this task, which is not a spike, got the Spike tag. :)

All the other tasks in Spike look ok to me, at a glance.

@Danny_B Thanks for clarifying, and sorry if I took an accusatory tone. I'm glad, either way, that all was accounted for. :)

In T138380#2431574, @ksmith wrote:

To be fair, you said "All tasks", without qualifications.

Fair enough.

I didn't remember that it was you who did the research, so Max might not have either.

It's just few posts above in this task... ;-)

Ironically, this task, which is not a spike, got the Spike tag. :)

Taks about creation and archiving of projects are being marked with those projects. I just followed... ;-)

In T138380#2431591, @MBinder_WMF wrote:

@Danny_B Thanks for clarifying, and sorry if I took an accusatory tone. I'm glad, either way, that all was accounted for. :)

NP. @ksmith is right, I should have worded more descriptively (I just simply implied it would be obvious...)

In T138380#2431658, @Danny_B wrote:

Ironically, this task, which is not a spike, got the Spike tag. :)

Taks about creation and archiving of projects are being marked with those projects.

Some folks do, some don't. It's not that they "are being marked" always, afaik.

Reanimating this zombie thread. Now that there are subtypes (Bug, Task, Deadline, etc), and boards can be filtered on said subtypes, I wonder if this tag should be deprecated to mitigate redundancy.

One use case currently being employed are ticket templates/links. Subtypes would have to be a field that can be manipulated. I think this is via the form number, which may mean that the tag is not redundant (for instance, if someone wanted to identify a ticket as a spike AND give that ticket a deadline).

As part of the ongoing conversation with myself here, I noticed that there is a form for Spikes, specifically, and it includes a deadline section. :)

Yeah, I think with the "Spike" ticket type we can remove the tag. My only
question is would it apply retroactively (ie. would closed tickets with the
Spike tag "lose" that tag?). That could be a problem for record
keeping/finding old tickets. But for new stuff, I say dump it!

My only question is would it apply retroactively (ie. would closed tickets with the Spike tag "lose" that tag?). That could be a problem for record keeping/finding old tickets.

I believe old tasks would not lose the tag, as the tag would simply be archived. At the board level, you would not see the tag, but the tasks would retain it for posterity. Example:
https://phabricator.wikimedia.org/project/view/54/
https://phabricator.wikimedia.org/T763

Meta comment : This task is about creating a tag to identify spike tasks. The tag exists. Hence the task is resolved. If there is now a proposal to archive the Spike tag then that should be a separate followup task, mentioning this very task which has been resolved for three years...

T138380#2426594 implies that the Spike tag was created to filter on a workboard. Such filtering is also possible on a workboard for task subtypes: Change the filter view in the upper right corner: Choose Advanced Filter..., set the "Subtypes" field to "Spike", and execute the query.

This will first require proper documentation for teams. That means fixing T224417 plus updating https://www.mediawiki.org/wiki/Phabricator/Project_management#Boards which currently covers how to change the filtered view in one short sentence in the subsection "Columns".

For the records, there are currently 374 tasks that have a Spike tag.