On 06/12/17 00:21, Kevin Fenzi wrote: > Sorry to reply to myself here, but I meant to reply to this part and > forgot: > > On 12/05/2017 02:53 PM, Kevin Fenzi wrote: >> On 12/05/2017 01:56 AM, Daniel Pocock wrote: >> >>> My observation is that the people who "like" email are simply not aware >>> of the other options. There is a perception that it is easy and/or the >>> lowest common denominator. It is very easy for script developers to >>> write a couple of lines of code to generate an email. Over time email's >>> inefficiency is a huge cost to the Fedora project and any other >>> organization doing things this way. > I'm not sure I agree with this. Dashboards and point in time reporting > provides great information for some cases, but discrete history at each > change is also sometimes the information you want. Looking at the options in the other email, one of them was: "if a build breaks, should the build system talk to Bugzilla's API directly, opening a bug and closing it again next time the build succeeds?" That approach would satisfy the requirement about keeping history and the current state would always be visible through Bugzilla's iCalendar API (without any modification to Bugzilla) For the script that sends the dependency emails from buildsys, is there a place to report this as a feature request? Is it in Bugzilla or Github issues? >>> Think about it like this: somebody goes away for a 6 week extended >>> vacation and they come back to find 1000 automated email messages >>> waiting, I worked in one company where that was the way things were >>> done. The consequences: >>> >>> - the emails are sorted chronologically, not in priority order, so the >>> user doesn't know which emails to look at first >>> >>> - they don't know which emails have been fixed by somebody else >>> >>> - they don't know which emails somebody else is already investigating >>> >>> - if 50 of those emails relate to a single problem or incident, it is >>> not obvious which email represents the root cause of the problem > Sure. I personally filter emails into a number of buckets. So, when I > came back and had 1000 emails, most of them would already be filtered. > So, I would know I don't need to immediately look at mailing lists or > other things that are lower priority. I also sort emails but it takes a certain amount of effort for every developer to set up their rules and in the end it doesn't answer all of those questions, e.g. it doesn't tell you which emails have already been handled by somebody else while you were on vacation. >>> The person coming back to that inbox might spend 1 day just checking the >>> emails. Or maybe 2-3 hours each day during the week after their >>> vacation, without really working on them, just trying to work out which >>> issues were still open, which emails are duplicates, prioritizing them, etc. > I get a lot of email, but I don't think I have ever had to spend weeks > going through backlog. > I once worked in a company where I got over 100 emails on my first day and averaged 2,000 per month. My predecessor and his manager had been putting "| mail" into scripts and cron jobs for over 10 years. While it sounds absurd, this is how things end up if developers don't consciously and deliberately do things thoughtfully. This is why I feel it is so important for leading free software projects to be good role models in how we use email. >>> Even when people don't go on vacation, they are losing a bit of time >>> every day on such filtering chores. Add it all up and it is a huge cost >>> to organizations. As a large organization, Fedora "loses" more time >>> this way than a small organization. >>> >>> In contrast, another company I worked in had a strict policy against >>> emails, things couldn't be released into production unless they worked >>> with the dashboard. Any developer, sysadmin or manager could look at >>> the dashboard in the morning and quickly see the top 3 issues nobody was >>> working on. > Yeah, but what about: > > * You have added another maintainer to a package you maintain. You want > to watch their commits and tell them when you see something they should > change or do better on. - you could set a reminder for yourself to check their commits each morning - you could use fedmsg to create a rule for that, maybe with an expiry date, it would send you chat notifications when you are logged in but wouldn't leave a trail of emails - the chat message thing might know when you log in again and send a single notification about how many commits you missed overnight or whatever - or FMN could even create a task for you when there are new commits and if you don't close the task and more commits are made, it appends them to the existing task rather than sending new alerts > Or > > * You want to see the exact series of events that led up to a package > being fixed. This would be possible if everything was forced to go through Bugzilla or if FMN dumps everything into some big data store (or both of those together). Has anybody looked at capturing everything that passes through FMN? How many GB per day is it? Would there be a preference for PostgreSQL or NoSQL? > Or > > * You want to be notified immediately if some action takes place because > you want to talk to whoever is doing it to change a workflow. This is a lot like the first point about watching the commits from a new maintainer. > I think there is a place for dashboards and email and irc and mobile > phone alerts and ... it depends some on the thing and some on the person > who is getting it. Yes, I agree with letting people get email, chat and SMS on an opt-in basis. I think it is really great to offer people that choice. However, I feel that people will get a lot more value out of it if they only things they are notified about are the things they really chose to be notified about: otherwise, they may be happy at first but eventually it becomes tedious and they actually miss important things or turn everything off. Regards, Daniel _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
