Our plan has been to have all Search&Discovery issues managed in the Search-Team phabricator project, and then for each subteam to have a sprint board for its current work.
However, Yuri pointed out that people wanting to create a new task related to maps would expect to add it to a project with "maps" in the name. Folks outside our team often would not realize that maps are part of the Search vertical.
We really want to consolidate all of our product backlogs in one place, to help keep Dan sane. So I don't think keeping an external high-level "Maps" project is a viable option. And I don't think adding the word "maps" to the main Search-Team project would make sense either. We might want to rename our top-level project to "Search-and-Discovery-Team" for other reasons, but that wouldn't help this specific case.
Even if we had a maps-related sprint board whose name would match a phab search for "map", that wouldn't be what we would want. We don't want random users dropping tasks directly into our sprint board. We really want new tasks to land in the product backlog first.
Is this just a case where we have to educate folks that "maps" work goes in "Search-Team"? Or are there other options?
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
For clarity, organizational consistency, keep maps under the Search and Discovery audience please. I understand it is not perfect and lets see how it plays out with communication, reserving the right to change this as we progress if it is a problem. We maintain a clear task for maps on the product wiki and engineering wiki for the year.
Maps is aligned with Search and Discovery. It is a function under our collective org which yes the top level needs to be called Search and Discovery. We could shorten to just Discovery but alas then search would also have the same challenges.
On Wed, May 13, 2015 at 1:33 PM, Kevin Smith ksmith@wikimedia.org wrote:
Our plan has been to have all Search&Discovery issues managed in the Search-Team phabricator project, and then for each subteam to have a sprint board for its current work.
However, Yuri pointed out that people wanting to create a new task related to maps would expect to add it to a project with "maps" in the name. Folks outside our team often would not realize that maps are part of the Search vertical.
We really want to consolidate all of our product backlogs in one place, to help keep Dan sane. So I don't think keeping an external high-level "Maps" project is a viable option. And I don't think adding the word "maps" to the main Search-Team project would make sense either. We might want to rename our top-level project to "Search-and-Discovery-Team" for other reasons, but that wouldn't help this specific case.
Even if we had a maps-related sprint board whose name would match a phab search for "map", that wouldn't be what we would want. We don't want random users dropping tasks directly into our sprint board. We really want new tasks to land in the product backlog first.
Is this just a case where we have to educate folks that "maps" work goes in "Search-Team"? Or are there other options?
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
I agree with Wes, we should keep things consistent.
That said, Yuri does raise a good point that I think needs addressing, which is that it'll be hard for users to find the right place to file a bug pertaining to maps. I don't know what the solution to this is at present.
Dan
On 13 May 2015 at 18:50, Wes Moran wmoran@wikimedia.org wrote:
For clarity, organizational consistency, keep maps under the Search and Discovery audience please. I understand it is not perfect and lets see how it plays out with communication, reserving the right to change this as we progress if it is a problem. We maintain a clear task for maps on the product wiki and engineering wiki for the year.
Maps is aligned with Search and Discovery. It is a function under our collective org which yes the top level needs to be called Search and Discovery. We could shorten to just Discovery but alas then search would also have the same challenges.
On Wed, May 13, 2015 at 1:33 PM, Kevin Smith ksmith@wikimedia.org wrote:
Our plan has been to have all Search&Discovery issues managed in the Search-Team phabricator project, and then for each subteam to have a sprint board for its current work.
However, Yuri pointed out that people wanting to create a new task related to maps would expect to add it to a project with "maps" in the name. Folks outside our team often would not realize that maps are part of the Search vertical.
We really want to consolidate all of our product backlogs in one place, to help keep Dan sane. So I don't think keeping an external high-level "Maps" project is a viable option. And I don't think adding the word "maps" to the main Search-Team project would make sense either. We might want to rename our top-level project to "Search-and-Discovery-Team" for other reasons, but that wouldn't help this specific case.
Even if we had a maps-related sprint board whose name would match a phab search for "map", that wouldn't be what we would want. We don't want random users dropping tasks directly into our sprint board. We really want new tasks to land in the product backlog first.
Is this just a case where we have to educate folks that "maps" work goes in "Search-Team"? Or are there other options?
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Kunal has also pushed back on the idea of eliminating feature-specific phab boards (like maps, although I think he was mostly referring to other similar cases). This seems like a decision that should be org-wide. Where and how should that discussion happen?
As for naming the main team project. I notice that Editing has the "Editing-Department" project. Should I rename our "Search-Team" phab project to "Search-and-Discovery-Department"?
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
On Thu, May 14, 2015 at 10:30 AM, Dan Garry dgarry@wikimedia.org wrote:
I agree with Wes, we should keep things consistent.
That said, Yuri does raise a good point that I think needs addressing, which is that it'll be hard for users to find the right place to file a bug pertaining to maps. I don't know what the solution to this is at present.
Dan
On 13 May 2015 at 18:50, Wes Moran wmoran@wikimedia.org wrote:
For clarity, organizational consistency, keep maps under the Search and Discovery audience please. I understand it is not perfect and lets see how it plays out with communication, reserving the right to change this as we progress if it is a problem. We maintain a clear task for maps on the product wiki and engineering wiki for the year.
Maps is aligned with Search and Discovery. It is a function under our collective org which yes the top level needs to be called Search and Discovery. We could shorten to just Discovery but alas then search would also have the same challenges.
On Wed, May 13, 2015 at 1:33 PM, Kevin Smith ksmith@wikimedia.org wrote:
Our plan has been to have all Search&Discovery issues managed in the Search-Team phabricator project, and then for each subteam to have a sprint board for its current work.
However, Yuri pointed out that people wanting to create a new task related to maps would expect to add it to a project with "maps" in the name. Folks outside our team often would not realize that maps are part of the Search vertical.
We really want to consolidate all of our product backlogs in one place, to help keep Dan sane. So I don't think keeping an external high-level "Maps" project is a viable option. And I don't think adding the word "maps" to the main Search-Team project would make sense either. We might want to rename our top-level project to "Search-and-Discovery-Team" for other reasons, but that wouldn't help this specific case.
Even if we had a maps-related sprint board whose name would match a phab search for "map", that wouldn't be what we would want. We don't want random users dropping tasks directly into our sprint board. We really want new tasks to land in the product backlog first.
Is this just a case where we have to educate folks that "maps" work goes in "Search-Team"? Or are there other options?
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
-- Dan Garry Product Manager, Search and Discovery Wikimedia Foundation
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
One option to allow users to find the right place is phab's "hashtags" feature. Currently, if you search for a project and type "openst", you will get the sprint project that has OpenStreetMap in the name, but you will also get the Maps project. The reason the Maps project comes up is because it has openstreetmap as a hashtag. If we removed that tag from the Maps project, and added it to the Search and Discovery Department project, then S&D D would come up as a search result for "OpenSt". We could do the same thing for all the other relevant hashtags, like map, maps, WDQS, WikidataQueryService, Wikidata-Query-Service, Cirrus, Elastic, etc, etc.
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
On Thu, May 14, 2015 at 10:37 AM, Kevin Smith ksmith@wikimedia.org wrote:
Kunal has also pushed back on the idea of eliminating feature-specific phab boards (like maps, although I think he was mostly referring to other similar cases). This seems like a decision that should be org-wide. Where and how should that discussion happen?
As for naming the main team project. I notice that Editing has the "Editing-Department" project. Should I rename our "Search-Team" phab project to "Search-and-Discovery-Department"?
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
On Thu, May 14, 2015 at 10:30 AM, Dan Garry dgarry@wikimedia.org wrote:
I agree with Wes, we should keep things consistent.
That said, Yuri does raise a good point that I think needs addressing, which is that it'll be hard for users to find the right place to file a bug pertaining to maps. I don't know what the solution to this is at present.
Dan
On 13 May 2015 at 18:50, Wes Moran wmoran@wikimedia.org wrote:
For clarity, organizational consistency, keep maps under the Search and Discovery audience please. I understand it is not perfect and lets see how it plays out with communication, reserving the right to change this as we progress if it is a problem. We maintain a clear task for maps on the product wiki and engineering wiki for the year.
Maps is aligned with Search and Discovery. It is a function under our collective org which yes the top level needs to be called Search and Discovery. We could shorten to just Discovery but alas then search would also have the same challenges.
On Wed, May 13, 2015 at 1:33 PM, Kevin Smith ksmith@wikimedia.org wrote:
Our plan has been to have all Search&Discovery issues managed in the Search-Team phabricator project, and then for each subteam to have a sprint board for its current work.
However, Yuri pointed out that people wanting to create a new task related to maps would expect to add it to a project with "maps" in the name. Folks outside our team often would not realize that maps are part of the Search vertical.
We really want to consolidate all of our product backlogs in one place, to help keep Dan sane. So I don't think keeping an external high-level "Maps" project is a viable option. And I don't think adding the word "maps" to the main Search-Team project would make sense either. We might want to rename our top-level project to "Search-and-Discovery-Team" for other reasons, but that wouldn't help this specific case.
Even if we had a maps-related sprint board whose name would match a phab search for "map", that wouldn't be what we would want. We don't want random users dropping tasks directly into our sprint board. We really want new tasks to land in the product backlog first.
Is this just a case where we have to educate folks that "maps" work goes in "Search-Team"? Or are there other options?
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
-- Dan Garry Product Manager, Search and Discovery Wikimedia Foundation
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Like this and yes to Search-and-Discovery-Department
On May 14, 2015, at 11:13 AM, Kevin Smith ksmith@wikimedia.org wrote:
One option to allow users to find the right place is phab's "hashtags" feature. Currently, if you search for a project and type "openst", you will get the sprint project that has OpenStreetMap in the name, but you will also get the Maps project. The reason the Maps project comes up is because it has openstreetmap as a hashtag. If we removed that tag from the Maps project, and added it to the Search and Discovery Department project, then S&D D would come up as a search result for "OpenSt". We could do the same thing for all the other relevant hashtags, like map, maps, WDQS, WikidataQueryService, Wikidata-Query-Service, Cirrus, Elastic, etc, etc.
Kevin Smith Agile Coach Wikimedia Foundation
Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.
On Thu, May 14, 2015 at 10:37 AM, Kevin Smith ksmith@wikimedia.org wrote: Kunal has also pushed back on the idea of eliminating feature-specific phab boards (like maps, although I think he was mostly referring to other similar cases). This seems like a decision that should be org-wide. Where and how should that discussion happen?
As for naming the main team project. I notice that Editing has the "Editing-Department" project. Should I rename our "Search-Team" phab project to "Search-and-Discovery-Department"?
Kevin Smith Agile Coach Wikimedia Foundation
Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.
On Thu, May 14, 2015 at 10:30 AM, Dan Garry dgarry@wikimedia.org wrote: I agree with Wes, we should keep things consistent.
That said, Yuri does raise a good point that I think needs addressing, which is that it'll be hard for users to find the right place to file a bug pertaining to maps. I don't know what the solution to this is at present.
Dan
On 13 May 2015 at 18:50, Wes Moran wmoran@wikimedia.org wrote: For clarity, organizational consistency, keep maps under the Search and Discovery audience please. I understand it is not perfect and lets see how it plays out with communication, reserving the right to change this as we progress if it is a problem. We maintain a clear task for maps on the product wiki and engineering wiki for the year.
Maps is aligned with Search and Discovery. It is a function under our collective org which yes the top level needs to be called Search and Discovery. We could shorten to just Discovery but alas then search would also have the same challenges.
On Wed, May 13, 2015 at 1:33 PM, Kevin Smith ksmith@wikimedia.org wrote: Our plan has been to have all Search&Discovery issues managed in the Search-Team phabricator project, and then for each subteam to have a sprint board for its current work.
However, Yuri pointed out that people wanting to create a new task related to maps would expect to add it to a project with "maps" in the name. Folks outside our team often would not realize that maps are part of the Search vertical.
We really want to consolidate all of our product backlogs in one place, to help keep Dan sane. So I don't think keeping an external high-level "Maps" project is a viable option. And I don't think adding the word "maps" to the main Search-Team project would make sense either. We might want to rename our top-level project to "Search-and-Discovery-Team" for other reasons, but that wouldn't help this specific case.
Even if we had a maps-related sprint board whose name would match a phab search for "map", that wouldn't be what we would want. We don't want random users dropping tasks directly into our sprint board. We really want new tasks to land in the product backlog first.
Is this just a case where we have to educate folks that "maps" work goes in "Search-Team"? Or are there other options?
Kevin Smith Agile Coach Wikimedia Foundation
Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
-- Dan Garry Product Manager, Search and Discovery Wikimedia Foundation
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Based on further feedback, the new proposal is:
The Search-and-Discovery phab project would be the single product backlog for all sub-teams. This is where Dan would do all the backlog grooming. Each sub-team would have a column, so their work would be separate.
We would retain (or add) feature-specific projects, like "Maps", "Cirrus-Search", etc. This would allow users in the community to file bugs against the Maps feature, or to see all of the open issues related to Cirrus. Phabricator would have a rule so that any task that got added to one of these feature projects would also automatically get added to the S&D product backlog project.
Each sub-team will have a Sprint project/workboard that reflects their work during roughly the previous, current, and next week. Weekly (give or take), Dan and the sub-team lead would copy tasks from the product backlog into that sub-team's sprint backlog. Sub-team members would focus all their attention on that sprint workboard.
When an issue is completed, Dan would mark it as resolved, which would remove it from the list of open issues on all 3 boards (sprint board, product backlog board, and feature-specific project).
I think this meets the following goals: - Dan has one place to look, for all long-term planning - Sub-team members can focus on a single (sprint) workboard - Community members can see all issues related to a specific feature - All the teams in our vertical follow a consistent pattern
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
On Thu, May 14, 2015 at 10:41 PM, Wes Moran wmoran@wikimedia.org wrote:
Like this and yes to Search-and-Discovery-Department
On May 14, 2015, at 11:13 AM, Kevin Smith ksmith@wikimedia.org wrote:
One option to allow users to find the right place is phab's "hashtags" feature. Currently, if you search for a project and type "openst", you will get the sprint project that has OpenStreetMap in the name, but you will also get the Maps project. The reason the Maps project comes up is because it has openstreetmap as a hashtag. If we removed that tag from the Maps project, and added it to the Search and Discovery Department project, then S&D D would come up as a search result for "OpenSt". We could do the same thing for all the other relevant hashtags, like map, maps, WDQS, WikidataQueryService, Wikidata-Query-Service, Cirrus, Elastic, etc, etc.
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
On Thu, May 14, 2015 at 10:37 AM, Kevin Smith ksmith@wikimedia.org wrote:
Kunal has also pushed back on the idea of eliminating feature-specific phab boards (like maps, although I think he was mostly referring to other similar cases). This seems like a decision that should be org-wide. Where and how should that discussion happen?
As for naming the main team project. I notice that Editing has the "Editing-Department" project. Should I rename our "Search-Team" phab project to "Search-and-Discovery-Department"?
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
On Thu, May 14, 2015 at 10:30 AM, Dan Garry dgarry@wikimedia.org wrote:
I agree with Wes, we should keep things consistent.
That said, Yuri does raise a good point that I think needs addressing, which is that it'll be hard for users to find the right place to file a bug pertaining to maps. I don't know what the solution to this is at present.
Dan
On 13 May 2015 at 18:50, Wes Moran wmoran@wikimedia.org wrote:
For clarity, organizational consistency, keep maps under the Search and Discovery audience please. I understand it is not perfect and lets see how it plays out with communication, reserving the right to change this as we progress if it is a problem. We maintain a clear task for maps on the product wiki and engineering wiki for the year.
Maps is aligned with Search and Discovery. It is a function under our collective org which yes the top level needs to be called Search and Discovery. We could shorten to just Discovery but alas then search would also have the same challenges.
On Wed, May 13, 2015 at 1:33 PM, Kevin Smith ksmith@wikimedia.org wrote:
Our plan has been to have all Search&Discovery issues managed in the Search-Team phabricator project, and then for each subteam to have a sprint board for its current work.
However, Yuri pointed out that people wanting to create a new task related to maps would expect to add it to a project with "maps" in the name. Folks outside our team often would not realize that maps are part of the Search vertical.
We really want to consolidate all of our product backlogs in one place, to help keep Dan sane. So I don't think keeping an external high-level "Maps" project is a viable option. And I don't think adding the word "maps" to the main Search-Team project would make sense either. We might want to rename our top-level project to "Search-and-Discovery-Team" for other reasons, but that wouldn't help this specific case.
Even if we had a maps-related sprint board whose name would match a phab search for "map", that wouldn't be what we would want. We don't want random users dropping tasks directly into our sprint board. We really want new tasks to land in the product backlog first.
Is this just a case where we have to educate folks that "maps" work goes in "Search-Team"? Or are there other options?
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
-- Dan Garry Product Manager, Search and Discovery Wikimedia Foundation
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
This sounds ideal.
On Mon, May 18, 2015 at 11:11 AM, Kevin Smith ksmith@wikimedia.org wrote:
Based on further feedback, the new proposal is:
The Search-and-Discovery phab project would be the single product backlog for all sub-teams. This is where Dan would do all the backlog grooming. Each sub-team would have a column, so their work would be separate.
We would retain (or add) feature-specific projects, like "Maps", "Cirrus-Search", etc. This would allow users in the community to file bugs against the Maps feature, or to see all of the open issues related to Cirrus. Phabricator would have a rule so that any task that got added to one of these feature projects would also automatically get added to the S&D product backlog project.
Each sub-team will have a Sprint project/workboard that reflects their work during roughly the previous, current, and next week. Weekly (give or take), Dan and the sub-team lead would copy tasks from the product backlog into that sub-team's sprint backlog. Sub-team members would focus all their attention on that sprint workboard.
When an issue is completed, Dan would mark it as resolved, which would remove it from the list of open issues on all 3 boards (sprint board, product backlog board, and feature-specific project).
I think this meets the following goals:
- Dan has one place to look, for all long-term planning
- Sub-team members can focus on a single (sprint) workboard
- Community members can see all issues related to a specific feature
- All the teams in our vertical follow a consistent pattern
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
On Thu, May 14, 2015 at 10:41 PM, Wes Moran wmoran@wikimedia.org wrote:
Like this and yes to Search-and-Discovery-Department
On May 14, 2015, at 11:13 AM, Kevin Smith ksmith@wikimedia.org wrote:
One option to allow users to find the right place is phab's "hashtags" feature. Currently, if you search for a project and type "openst", you will get the sprint project that has OpenStreetMap in the name, but you will also get the Maps project. The reason the Maps project comes up is because it has openstreetmap as a hashtag. If we removed that tag from the Maps project, and added it to the Search and Discovery Department project, then S&D D would come up as a search result for "OpenSt". We could do the same thing for all the other relevant hashtags, like map, maps, WDQS, WikidataQueryService, Wikidata-Query-Service, Cirrus, Elastic, etc, etc.
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
On Thu, May 14, 2015 at 10:37 AM, Kevin Smith ksmith@wikimedia.org wrote:
Kunal has also pushed back on the idea of eliminating feature-specific phab boards (like maps, although I think he was mostly referring to other similar cases). This seems like a decision that should be org-wide. Where and how should that discussion happen?
As for naming the main team project. I notice that Editing has the "Editing-Department" project. Should I rename our "Search-Team" phab project to "Search-and-Discovery-Department"?
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
On Thu, May 14, 2015 at 10:30 AM, Dan Garry dgarry@wikimedia.org wrote:
I agree with Wes, we should keep things consistent.
That said, Yuri does raise a good point that I think needs addressing, which is that it'll be hard for users to find the right place to file a bug pertaining to maps. I don't know what the solution to this is at present.
Dan
On 13 May 2015 at 18:50, Wes Moran wmoran@wikimedia.org wrote:
For clarity, organizational consistency, keep maps under the Search and Discovery audience please. I understand it is not perfect and lets see how it plays out with communication, reserving the right to change this as we progress if it is a problem. We maintain a clear task for maps on the product wiki and engineering wiki for the year.
Maps is aligned with Search and Discovery. It is a function under our collective org which yes the top level needs to be called Search and Discovery. We could shorten to just Discovery but alas then search would also have the same challenges.
On Wed, May 13, 2015 at 1:33 PM, Kevin Smith ksmith@wikimedia.org wrote:
Our plan has been to have all Search&Discovery issues managed in the Search-Team phabricator project, and then for each subteam to have a sprint board for its current work.
However, Yuri pointed out that people wanting to create a new task related to maps would expect to add it to a project with "maps" in the name. Folks outside our team often would not realize that maps are part of the Search vertical.
We really want to consolidate all of our product backlogs in one place, to help keep Dan sane. So I don't think keeping an external high-level "Maps" project is a viable option. And I don't think adding the word "maps" to the main Search-Team project would make sense either. We might want to rename our top-level project to "Search-and-Discovery-Team" for other reasons, but that wouldn't help this specific case.
Even if we had a maps-related sprint board whose name would match a phab search for "map", that wouldn't be what we would want. We don't want random users dropping tasks directly into our sprint board. We really want new tasks to land in the product backlog first.
Is this just a case where we have to educate folks that "maps" work goes in "Search-Team"? Or are there other options?
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
-- Dan Garry Product Manager, Search and Discovery Wikimedia Foundation
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search