<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi Kent,<br>
      <br>
      On 30/11/2013 00:50, Kent James wrote:<br>
    </div>
    <blockquote cite="mid:5299365D.7040303@caspia.com" type="cite">I
      have now put a page up on the Mozilla Wiki that describes the
      donation link proposal:
      <br>
      <br>
      <a class="moz-txt-link-freetext" href="https://wiki.mozilla.org/Donations_Proposal">https://wiki.mozilla.org/Donations_Proposal</a>
      <br>
    </blockquote>
    Thanks for putting this together. I've got a few comments, so I'll
    just jump in with those:<br>
    <br>
    - I expect you'll head towards this anyway, but I would say
    generally it would be better to have a clean distinct proposal
    separate from personal feelings/suggestions. Have rational sections
    if you need them, but having it separated out, would make it easier
    to work out what is being asked for, separate to the why.<br>
    <br>
    - I would certainly object to putting a donation link in the way you
    describe. To me, having a permanently visible link on primary UI
    feels like begging, and doesn't feel appropriate. Maybe I'm a bit
    sensitive to donation areas but having something you can't get rid
    of without doing something (or reading something about donating)
    doesn't sound in keeping with something that has always been billed
    as free software.<br>
    <br>
    I would not mind links on the start page, or in other areas e.g. the
    about dialog.<br>
    <br>
    I would also certainly prefer to start small and increase visibility
    gradually, as this would allow feedback and questions to be resolved
    before pushing out to a wide audience.<br>
    <br>
    - Hiring Contractors. I didn't get around to saying this earlier,
    but I think this may be difficult to do in a fair manner, unless you
    go for people who have never contributed to Thunderbird, as
    otherwise there could be significant bias in who gets selected.<br>
    <br>
    - "
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    Support for ongoing expenses of possible server-based innovations" -
    I think this may be better described as "Support for external
    projects directly related to Thunderbird innovation". As really I
    think what you describe would be external projects, and so we should
    just be up front about that.<br>
    <br>
    - I see one of the responsibilities of the module owners & peers
    group to take feedback from support, QA et al. Not doing so, would
    likely lead to a very developer product, rather than a user based
    product. I think therefore support and QA do have a big voice.<br>
    <br>
    - As I've mentioned in the past, I still believe that the existing
    module owners & peers group could do a lot more than what we
    currently do, especially wrt to decision making/direction setting.
    Some of this could easily be managed via the weekly meeting, but I'm
    not sure I'm seeing the questions/discussions around what people
    should do or be focussing on. <br>
    <br>
    There's a two-way process here, of setting what the focus is, and
    then contributors acting on that. We tried this before last year,
    and it didn't seem to work. Did we do any analysis as to why?<br>
    <br>
    - Quoting an assumption for amount of funds available doesn't
    actually appear to help or benefit the proposal.<br>
    <br>
    - The expanded groups for decision making doesn't actually seem that
    useful. It feels more like a formal way to detail what I mentioned
    earlier where module owners already take feedback from other groups.<br>
    <br>
    It is unclear who or what the finance group would consist of, or who
    it operates and I think that is one of the critical parts of the
    proposal.<br>
    <br>
    Mark<br>
  </body>
</html>