[newmaint-site] Work on nm.debian.org

[Enrico Zini]

On Tue, Aug 27, 2013 at 12:40:57AM +0200, Marco Bardelli wrote:

> Hi guys, the TODO list kindly published by Enrico
> at https://wiki.debian.org/Teams/FrontDesk/NmSiteDevel
> does not seem so long, yet.

:) I'm trying to keep random unclear requests out of it, to the best of
my understanding.


> Just to recap, the mail notification to the applicant issues are:
> - When an AM approves the applicant, mail
>   debian-newmaint at lists.debian.org ...
> - email notification to the applicant when they get in the queue to get
>   an AM assigned (status app_ok)
> - email notification to the applicant when they get approved by the AM,
>   saying what is now going to happen: FD will do consistency checks, and
>   then pass it on to DAM to decide
> - email notification to the applicant when they get approved by FD,
>   saying that now it's up to DAM to have a look and do the final
>   approval.
> 
> the signal hook "pre_save" on Process model, seems to me a good
> approach, although it requires an additional query db at every save to
> detect interesting changes. If it also seems a proper way to proceed to
> you, too, I can take these tasks, claiming them on the wiki.

I like the idea of a generic approach, and of having the state
machine-like triggers all in one place. I admit that I've never really
used Django signal hooks, though.

I'll try and give more detail on what would trigger those emails:
essentially, you need to know the previous and next value of
Process.progress. If it can be done with signals, that'd be awesome.
If not, such transitions can be implemented by ad-hoc methods like
Process.finalize: there are not many views that trigger these changes.

 * When an AM approves the applicant, mail debian-newmaint

   This happens only when Process.progress goes from one of (am_rcvd,
   am, am_hold) to am_ok.
   
   Use case: the AM can decide to approve an applicant whatever previous
   progress they were in.
   
   The email shouldn't however be triggered if, for example, FD just
   unholds an application but hasn't finished with their review: that
   would be a (fd_hold -> am_ok) change.


 * When they get in the queue to get an AM assigned

   This happens when Process.progress goes from [anything except app_ok]
   to app_ok.
   
   Use cases:
    - FD may skip any step from initial contact to having things ready
      for AM assignment
    - an AM may get busy and hand an applicant back to FD. That would be
      a transition from any of (am_rcvd, am, am_hold) to app_ok


 * When they get approved by the AM, say what is going to happen

   This is the same trigger as mailing debian-newmaint


 * When they get approved by FD

   This happens only when Process.progress goes from one of (am_ok,
   fd_hold) to fd_ok.



> I did not populate my local db yet, cause I can't "export nm db". I'll
> try to generate some fake data, if is not possible for any DD to post a
> minimal json.

Sent via private mail.


> I'll continue to work on short bio, showing it on "/public/person"
> under "Application Manager" in a fancy way,
> maybe with some expandable/collapsible via js.

Cool!


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico at enricozini.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/newmaint-site/attachments/20130827/8f11ab4e/attachment.sig>