On Sun, Jan 6, 2019 at 10:52 AM Roy Lenferink <rlenfer...@apache.org> wrote: > > Hi all, > > (Coming from the comdev mailing list where the same idea/feature request > popped up.) > > I think this is quite a good idea and I want to help out with this idea as > well. > > As I haven't worked on Whimsy before I first want to be familiar with the way > of working for Whimsy. Is everyone having a local setup to use for > developing, or is there a development VM available for Whimsy? It's not a > problem to setup something locally though. > > Are the files DEVELOPMENT.md [1] and CONFIGURE.md [2] still up-to-date to get > started with developing on whimsy?
Short answer: the following is the most up to date: https://github.com/apache/whimsy/blob/master/MACOSX.md Longer answer: over the years, I've tried creating a VM (using vagrant/chef), a Dockerfile, and generic (non-O/S specific) instructions. Other than one individual (Brett Porter) using the Dockerfile a few times, none of these got much traction. What did work was Mac OS/X specific instructions. So, consider those instructions tested, and any other instructions and "thought to work, but untested". What is your development O/S? > - Roy > > [1] https://github.com/apache/whimsy/blob/master/DEVELOPMENT.md > [2] https://github.com/apache/whimsy/blob/master/CONFIGURE.md - Sam Ruby > On 2018/12/17 17:32:52, sebb <seb...@gmail.com> wrote: > > The current moderation system is quite inefficient as every moderator > > gets every mail and needs to review each one to decide what to do. > > > > There's no sharing of effort. > > > > This issue has been solved for the case of some ASF lists (announce, > > press, etc), by using a shared GMail account. However the solution > > only applies where all moderators are allowed access to all lists. > > Also it would not be scaleable for project lists. > > > > So I've started looking at what might be required to use Whimsy to > > moderate mails, e.g. using a modified version of the Secretary > > workbench. > > > > The workbench implements a dynamic list of unprocessed mails. > > As soon as a mail has been processed, it disappears from the list, so > > generally only one moderator would need to view each email. > > > > There are potential advantages of using a custom solution (rather than > > GMail). > > > > Many times, the same spam is sent to multiple lists. So there is scope > > for automatically detecting and ignoring all similar mails. And if a > > mail is manually detected as spam, all similar mails can be marked > > likewise. > > > > Where an email is to be rejected (e.g. wrong list), it would be easy > > to provide template replies. > > > > The workbench would receive all moderation requests, and only show > > those for which the user has karma. [There might need to be further > > filtering to reduce the load for ASF members.] > > > > If the UI is carefully designed, I think this would make a moderators > > job much easier, and should mean fewer moderators are needed overall. > > > > Some figures: > > 250-1000 mod requests per day; average around 700 across all lists > > (public and private) > > 150-200+ 'obvious' spam mails (duplicates across multiple lists) > > > > Sebb. > >
