Re: task 8833 -- proposed steps -- improving the design

[Davi Leal]

Federico Gimenez Nieto wrote:
> > Hmm. Maybe we could just rename the R1_Donations2JobOffersJoins table to
> > D1_Donations.  We could think a week more about such renaming. If we
> > follow thinking that the next Saturday then we can do such renaming.
>
> Ok,  we could even keep the R1_Donations2JobOffersJoins for the
> Donations-JobOffers join information and the D1_Donations for the
> Donations-only information...

The Donations-only information would be just 3 fields.  Adding a new table we 
add complexity to the data base schema. IMHO it is not needed.  Note for 
example that at the J1_JobOffers table we not add a new table for each field 
set.


CREATE TABLE R1_Donations2JobOffersJoins (
  -- Identifiers
  R1_Id        SERIAL PRIMARY KEY,
  R1_J1_Id     integer REFERENCES J1_JobOffers(J1_Id) NOT NULL,
  R1_E1_Id     integer REFERENCES E1_Entities(E1_Id) NOT NULL,

  -- The donation
  R1_Donation  varchar(15) NOT NULL,

  -- To confirm donation
  R1_DonationMagic        varchar(512) DEFAULT NULL,
  R1_DonationMagicExpire  timestamp NOT NULL DEFAULT 'now'
);



> > Proposal:
> >
> >   Shows too non-verified donations. So the webapp will give immediate
> >   feedback to who add a donation, even if [s]he is not logged.
> >
> >   If it is not verified it will just deleted. So no problem.
> >
> > IMHO, the webapp giving feedback to users is good. When I donate I want
> > to see my donation listed immediately, even if I will verify tomorrow.
>
> For the user which makes the donation is good to see his not-yet confirmed
> donations as soon as possible, but, what about the rest of users? They
> could see a donation one day and not the next day, because for any reason
> it has not been confirmed.

That is no problem.  Note donators who pledge can just _cancel_ at any time 
their already-confirmed-donations.  They can just log in, go to the 'notices' 
menu, list their pledges and cancel one or all of them.


So, say I begin to work out the tasks exposed at the [1] pledge group. They 
are $8001 USD!  I want such money :-)

  [1] http://gnuherds.org/pledges?id=57

However, Dave Crossland decides cancel his pledge. I lose my time.  To 
mitigate that the GNU Herds project has several options:

 1. Force donators to deposit the money in a bank account managed by the
    GNU Herds association. So such donations are guaranteed by the GNU Herds
    association.

    However, that is complex to design, implement and mainly to maintain.

    Such task is delayed:  You could read the email thread at:
    http://lists.gnu.org/archive/html/gnuherds-app-dev/2008-07/msg00014.html

    IMHO the GNU Herds project must add features on demand, following
    common sense, etc.

 2. Another option: Make it easier the contact between donators and workers.
    So, when you add yourself as worker or as donator you see the other
    emails, so you can negotiate with donators the way to get the money. For
    example:

      a)  You show the design  ->  You get 15% of donations.
      b)  You show an alpha version  ->  You get another 30%.
      c)  You show a beta version  ->  You get another 30%.
      d)  You show the final version  ->  You get the final 25%.


    Asking for a down payment is risky for donators, due to they are
    not sure if they will get some result.

    Asking for showing some results first is risky for workers, due
    to they are not sure they will get some money.

    At my company this is solved writing the functional-requirement
    document and signing it with the customer.  No more, no less.


    If the task is small, you could show it done and you get the 100%
    if it is accepted.

    Abstract:  Workers will have to negotiate it with donators.


    Right now GNU Herds do not guarantee workers will get the money or
    that donators will get the tasks done.


> > Additionally, note if we keep it inside such method we could use a
> > common text for all email. A more abstract and common text will do
> > the translator task easier due to they will have less msgid to
> > translate. 
> >
> > Proposed "policy":
> >
> >   Try to reduce the number, length and complexity of msgid to
> >   translate if it is possible, but without damage the webapp.
> >   Just use the common sense.
>
> I totally agree, we should avoid code duplication as much as possible,
> along with other benefits, this leads to less msgids. In this case i think
> that there could be alternative options, without code duplication and
> without violating the separation of concerns: what do you think about a
> separate mailing class?

I think it could be interesting :)

Right now, the webapp is sending emails at:

  * crontabs/raise_Alerts.php
  * Layer-2__Business_logic/content/forms/Entity_form.php
  * Layer-2__Business_logic/content/forms/Lost_Password_form.php
  * Layer-5__DB_operation/Entity.php

So, we can think such class as a general library. Therefore, we could add the 
mailing class at:

  * lib/Mailing.php



What do you think? As usual we could be mistaken.




P.S.: I think you are breaking the email threads again. I do not see the below 
entries in the source of your last reply:

    References:   ..value..
    In-Reply-To:  ..value..

Are you using the "Reply to all" or "Reply to" functions of your email 
client?