I Mapillary closing up?

1

I’m a bit concerned about where my contributions go - I don’t feel like working for free for Google or Waze, but working for free to create a dataset that benefits us all (if some may profit from it, that’s even better) is a great thing.

I’ve been a bit edgy about the openness of Mapillary, as evident from the “How open is Mapillary?” thread back in 2016. Overall, it has fared pretty well, providing a great platform for us OpenStreetMap enthusiasts, as well as being a decently open platform overall. They have also done this while keeping afloat financially, which is a hidden side for all of us here, but surely a great achievement.

A few days ago I noticed emails coming from the public issue about Mapillary things (applications, website and others). At first I got happy, as I thought “Oh, the app won’t kill our devices anymore by rewriting all images just to add EXIF tags”, but the messages put me down[1][2][3]:

mapillary_issues is no longer an active repository.

This issue has been moved over to our internal task list. Please send an email to support@mapillary.com with a reference to this issue if you want to add more information, or want to be notified once it’s been fixed!

There are many things to be concerned about, the first few that come to my mind:

  • No way to provide additional input on issues that affect multiple contributors
  • No way to see what issues others have faced
  • No way to see any progress on the reported issues

This is disappointing and disturbing. There might be many reasons, a few most likely ones:

  • Aiming for more investor money and improving the image
  • Preparing to sell the company and improving the image

I don’t expect an honest and full answer from Mapillary employees not because they are evil or something - they are wonderful, hard working and brilliant individuals. But they are entangled financially, possibly with NDAs, and would not be able to be speak their minds.

It is more expected that the community would be able to speak their mind and reveal whether they care about the continued open, honest communication. Surely the example of people working for free for Waze shows that many are fine with their contributions being locked away - and there’s this sad possibility that Mapillary might be going in that direction soon.

Having said that, I’d expect all contributors to be polite, maybe even more than usually so. This is people making decisions because of financial reasons, and having full legal rights to do so. If somebody feels that this is unacceptable, it is not OK to trash the people behind the project/company.

[1] https://github.com/mapillary/mapillary_issues/issues/2861
[2] https://github.com/mapillary/mapillary_issues/issues/2100
[3] https://github.com/mapillary/mapillary_issues/issues/2798

5 Likes
2

i dont know much about how these things work but it seems like they are putting a fair bit of work into the product for something they are trying to sell, like adding organisations last month and also updating the sign recognition.

…but that is just me presuming that most companies stop spending money or resources once they are trying to sell

3

Regarding the issues repository, I just got this:

mapillary_issues is no longer an active repository.

Let’s continue discussing features in our forum! We will import this issue as topic to the Mapillary Forum in the coming weeks. We’ll notify here once it’s been done. See you there!

It would be great with some details on why, perhaps @Sandra can help?
My consern is, that now we have no public place to post issues where someone will look at it.

I don’t think Mapillary are closing or going evil. I think they are very busy meaning they don’t always put the work into the community oriented tools that we would like. There have been many bugs making life hard for us, or just preventing us for fixing mistakes - which has always been really hard. APIs changing when you just get something to work etc. in OSM we are used to that the community fixes the stuff and you can do it yourself, but here we have to work with a private entity that needs to make money to pay the people who do it all.

1 Like
4

Hi @richlv

Thanks for this - we really appreciate you taking the time.

We do everything we can to serve the community, and to make sure that our images and map data remain openly available to all. The decision to close mapillary_issues is to better serve the community and to improve how we fix issues.

The short answer:
We have outgrown this process we put in place in the early days of Mapillary.

Here’s the longer answer:
As both the Mapillary team and the community has grown mapillary_issues has turned into an ineffective channel. It was great in the beginning when we were a small team but doesn’t work anymore. Urgent issues, like bugs or severe problems, and not-so-urgent issues, like feature requests, were grouped together with little structure.

What we’re doing now is encouraging issues submission to support@mapillary.com, where we now have a full-time person triaging bug reports, and any problems or issues people might have with using Mapillary. Next to that, the Mapillary forum - open and transparent - is a good place to discuss everything from requested features, ideas, to issues you’ve submitted to support.

Getting issues to support@mapillary.com, the development team can focus on development and the support team can ensure fast first response times and make sure issues get elevated appropriately.

We’re going to try this new structure and see how it goes. The support team has thought hard about this and we’re hoping that collecting the conversation in one place, the Mapillary forum, will make it better for everyone. It is also a more accessible channel for non-technical people.

Streamlining this process means better response times, better resolutions, and honest answers when we are unable to implement a feature request.

Thanks for your understanding and your feedback!

5 Likes
5

Hi @tryl

(See my other reply for more details)

If the issues need support, better they be handled quick in a structured way by our support team. If discussions or feature ideas, the forum does a better job than a bug tracker.

I know we have had bugs and problems where we have been slow at fixing sometimes. We have at times been completely understaffed for all the things we want to do and operating Mapillary in 2018 is a much bigger effort that when we were a four-person team. We’re growing, and growing up, and we’re now much better positioned than ever to give the service level a platform like Mapillary deserves.

Thanks for sticking with us!

4 Likes
6

Thanks for the long and detailed explanation @jesolem. As a fairly new user of Mapillary and as someone working in software development field I’m quite fond of open bug reporting tools, like Jira, Bugzilla and your own mapillary_issues repository.

The reasons being that:-
1- you get to see a list of all open issues
2- if you come across an issue, you can check if someone has reported it already and you can either leave it or add your own additional comments to help developers see a ‘bigger picture’ so to speak,
3- you can see which issues have been triaged, which are still open, which ones are being prioritised, etc.

Instead, we’re now being asked to send email to support@mapillary.com with your issues. The downside I see from this are:-
1- as stated earlier, we don’t know if others have reported a similar issue, if it’s going to be fixed, if it’s already planned for a fix in the next update, etc.
2- we don’t get any feedback on how the issue we reported is being progressed.

I’ve not used support@mapillary.com to submit issues, so I don’t know what kind of feedback I’d get from that process. Even if we do get some sort of email feedback, as a user I’d now have to sort through my emails to see how many issues I’ve reported, when I reported them, what’s the latest progress on those issues, etc. rather than going to a site to see all those issues in one place.

I know Mapillary is not an open-sourced product so you have no obligation to make your internal process public but how refreshing it would be if it is so. In my previous job I was a QA Lead for a company and our team produced a commercial API as well as a mobile app, and we provided a public JIRA project for our users to report bugs and an internal JIRA for our Dev team. I triage all the issues on the public JIRA and respond directly to the users, and all issue that need to be fixed are imported to internal JIRA for the Dev team to handle in our own dev cycles.

I know you said the support team has thought long and hard about this, but can we not do something similar, now that you have a full-time person managing this process?

Thanks

2 Likes
7

Good feedback, thanks @laye

Let us wrap up this current transition and then see if we can do something similar with our support person (team) going forward.

2 Likes
8

Edit =

I misunderstood “localization”.

Sometimes I write before I read.

9

FWIW, my two cents. I have sent similar feedback to Mapbox in the past.

For me as a user, a switch away from Github Issues is a big step backwards. Some reasons:

  • I spend lots of time on Github, so it’s convenient to have issues from many projects accessible in one place. I’m not going to go out of my way to visit many (any?) forums.
  • Raising a Github issue is a public event. I like the two-way accountability of that. The company can’t really just ignore the issue.
  • Raising a Github issue contributes to my public profile. I like to be able to show people the stuff I have contributed to in various ways.
  • Seeing a user-facing issue linked to actual code that fixed it is amazing. So rewarding.
  • Going through a support staff layer is really tiresome. Originally, Mapbox’s support email went straight to the dev team and you got great responses. Then it became just an extra layer that weren’t adding any value for me. I imagine similar may happen here.
  • I find support by email tends to be full of all kinds of noise like “Thanks we got your email and will respond soon!” and “Is there anything else we can help you with, or can I close this ticket” and “Your ticket has been closed” and “How did we do? Click here to rate the support you just received”. Whereas Github Issues discussions tend to be really to-the-point.

So: it’s totally possible that this transition will “serve the community better” as a whole, but it definitely serves some members of that community, like me, a lot worse.

(I should clarify that I’m not really an active Mapillary user atm, but I just really like giving feedback. :))

1 Like
10

I’m looking forward to see how e-mail is going to solve this. You replace an open, searchable bin where everybody can send their ideas and issues, with one that is closed and not searchable, but is just as unstructured…

Asking to use the e-mail address only for bug reports, is going to work just as good as asking to use the GitHub tracker only for bug reports.

2 Likes
11

@jesolem, thank you for the response.

I’m puzzled whether that is indeed your view on this topic:

If the issues need support, better they be handled quick in a structured way by our support team. If discussions or feature ideas, the forum does a better job than a bug tracker.

Using a public issue tracker can be done in a structured way. Presumably, an issue tracker is still used internally.

Using a forum to discuss feature requests does not replace an issue tracker, it complements it. If a feature request needs longer discussion, one can always link to a forum thread from the report. On the other hand, forum lacks the “tracking” part of the issue trackers. It makes it harder for users to find out whether something they are seeing is a known issue or not (for example, no background upload on iOS), thus their only option is now to send an email. At Mapillary, somebody has to read and respond to that email (and this cannot be offloaded to community).

This scales much, much worse than a public tracker, and could work only by alienating the community so that they stop reporting issues.

Additionally, closing up the reports means that I as a contributor have to spend more time discovering problems, or reporting them (for example, if my report does not have all the info a developer might need, somebody else can add helpful detail). Even worse, this wastes time by forcing contributors to report things that are well known. Do I spend time to write a detailed report after searching an issue tracker and not finding anything, or do I drop an email with sparse info thinking “probably 20 people have spent time reporting this anyway”?

It seems to me that the stated reasons are not true. I would appreciate some reasoning on how a closed bug tracker + an unstructured forum avoids the problems, listed above - but of course Mapillary is free to do as they wish. Unfortunately, the current direction takes away the time I could spend contributing better imagery.

2 Likes
12

Hi @Richlv

Appreciate your feedback, thanks for your input. There are several angles here.

  • Support and problems using the service: We have a proper solution for that, with tracking, and dedicated people now and I think this is the right way to handle that.
  • Feature requests and discussions: This was the reason we started the forum in the first place and I think this is superior to using a bug/issue tracker.
  • Issues and bugs: This is the tricky one and I see your point. Let’s dive deeper into that.

We have issue trackers (Github) that we use internally. In the very early days of Mapillary when we were a very small group of people all hacking away at our laptops, all developing, we actually used mapillary_issues as our bug tracker. The problems came when we started to grow and got multiple internal teams working on different parts of the system (iOS, Android, backend, website, viewer, computer vision, …). Each team had their own issue tracking in the repos they work on and we had to map mapillary_issues to internal ones, follow up and report back. This did not work and led to the public issues being left hanging in many cases. It was many years since mapillary_issues was our main issue tracker and we are now over 50 people working full-time.

I see the point of searching for issues and if we can find a way to solve this we will. For now, just send a quick note to support.

We’re not closing up but growing and adding structure. The discussions on the forum are just as public as they have been on mapillary_issues. The support cases are handled professionally.

/Jan Erik

6 Likes
13

Thank you so much for the response.
The main problem is that this closing of the issues makes it harder to contribute to Mapillary. I’ve stopped reporting bugs or checking for feature improvements, as shooting some emails without a public record seems like a waste of my time. In the end it makes me a bit less likely to take pictures.

Many organisations, for example RedHat, do have a public tracker with private or internal issues/bugs. Imagine RedHat closing their public bug tracker - would it make users more or less likely to contribute and continue be users?

I stumbled on some other thread on this, so there seem to be a few users who don’t fancy the closing up of issues that much: Page not found .

Now, regarding how this could be handled… Without knowing the internals I cannot suggest that much, but as you mentioned you use Github internally anyway, it seems like keeping the platform is the best bet. I’ve seen quite a few teams manage public + private issues fairly well, and even with manual syncing the effort was well worth the benefits it provided (less duplicated effort, better relationship with the community etc).

You said that “This did not work” for Mapillary. Is it possible to expand on that a bit? Was it an organisational culture issue, with some contributors thinking the public issues - and community - are not worth the attention, or something else?

2 Likes
14

There are some many things wrong, I don’t know where to begin.

15

@filipc, sorry, that comment did not seem to provide much useful information. Could you please find some time to formulate your thoughts in a bit more detail?

16

I understand @filipc’s feelings, there are quite a lot of bugs and problems. I’ve been reporting many of them over the years, but there is little to no follow-up. Even with the public bug tracker, I’ve reported bugs that got no response whatsoever for over a year, and then were closed, some even without comment, because they were so old, or because there was a new version, or because they wanted bugs reported in a different way, or whatever.

Mapillary at the moment seems more interested in working with the car manufacturing industry than with its contributors.

4 Likes