5 service-level agreement to somehow "bind" their developers to answering questions
source | link

Source code in form ready to open in specified IDE

above, though nice to have, feels rather slippery - leaving too much room to fuss over IDE version, plugins, configuration. "oh by the way this will work only if you install and enable Habracadabra plugin v 6.6.6. And, hey, just in case if you don't know, this version of Habracadabra works only with Netclipse 3.4.5"

  • When taking over I'd prefer to insist on having source code ready to build from command line

  • Also, in case if "they" use issue tracker for the project, I would do my best to squeeze all the data about these issues somehow (all issues in tracker, no matter fixed or not) - either by completely taking over that issue tracker with or by getting a read-only access to it or at least by getting a "snapshot" of it by whatever means.
     
    Information stored in an issue tracker might be a great help for maintainer


update Can't tell if this qualifies as an artifact but given details provided later, I'd consider some sort of service-level agreement to somehow "bind" their developers to answering questions about the application.

  • "For first 3 (4,5) months mean time to answer within 8 hours, assuming 100 or less questions a week. For next 3-6 months mean time to answer within 24 hours, assuming 10 or less questions a week..."

Source code in form ready to open in specified IDE

above, though nice to have, feels rather slippery - leaving too much room to fuss over IDE version, plugins, configuration. "oh by the way this will work only if you install and enable Habracadabra plugin v 6.6.6. And, hey, just in case if you don't know, this version of Habracadabra works only with Netclipse 3.4.5"

  • When taking over I'd prefer to insist on having source code ready to build from command line

  • Also, in case if "they" use issue tracker for the project, I would do my best to squeeze all the data about these issues somehow (all issues in tracker, no matter fixed or not) - either by completely taking over that issue tracker with or by getting a read-only access to it or at least by getting a "snapshot" of it by whatever means.
     
    Information stored in an issue tracker might be a great help for maintainer

Source code in form ready to open in specified IDE

above, though nice to have, feels rather slippery - leaving too much room to fuss over IDE version, plugins, configuration. "oh by the way this will work only if you install and enable Habracadabra plugin v 6.6.6. And, hey, just in case if you don't know, this version of Habracadabra works only with Netclipse 3.4.5"

  • When taking over I'd prefer to insist on having source code ready to build from command line

  • Also, in case if "they" use issue tracker for the project, I would do my best to squeeze all the data about these issues somehow (all issues in tracker, no matter fixed or not) - either by completely taking over that issue tracker with or by getting a read-only access to it or at least by getting a "snapshot" of it by whatever means.
     
    Information stored in an issue tracker might be a great help for maintainer


update Can't tell if this qualifies as an artifact but given details provided later, I'd consider some sort of service-level agreement to somehow "bind" their developers to answering questions about the application.

  • "For first 3 (4,5) months mean time to answer within 8 hours, assuming 100 or less questions a week. For next 3-6 months mean time to answer within 24 hours, assuming 10 or less questions a week..."
4 this version of _Habracadabra_ works only with Netclipse 3.4.5
source | link

Source code in form ready to open in specified IDE

above, though nice to have, feels rather slippery - leaving too much room to fuss over IDE version, plugins, configuration. "oh by the way this will work only if you install and enable Habracadabra plugin v 6.6.6"6. And, hey, just in case if you don't know, this version of Habracadabra works only with Netclipse 3.4.5"

  • When taking over I'd prefer to insist on having source code ready to build from command line

  • Also, in case if "they" use issue tracker for the project, I would do my best to squeeze all the data about these issues somehow (all issues in tracker, no matter fixed or not) - either by completely taking over that issue tracker with or by getting a read-only access to it or at least by getting a "snapshot" of it by whatever means.
     
    Information stored in an issue tracker might be a great help for maintainer

Source code in form ready to open in specified IDE

above, though nice to have, feels rather slippery - leaving too much room to fuss over IDE version, plugins, configuration. "oh by the way this will work only if you install and enable Habracadabra plugin v 6.6.6"

  • When taking over I'd prefer to insist on having source code ready to build from command line

  • Also, in case if "they" use issue tracker for the project, I would do my best to squeeze all the data about these issues somehow (all issues in tracker, no matter fixed or not) - either by completely taking over that issue tracker with or by getting a read-only access to it or at least by getting a "snapshot" of it by whatever means.
     
    Information stored in an issue tracker might be a great help for maintainer

Source code in form ready to open in specified IDE

above, though nice to have, feels rather slippery - leaving too much room to fuss over IDE version, plugins, configuration. "oh by the way this will work only if you install and enable Habracadabra plugin v 6.6.6. And, hey, just in case if you don't know, this version of Habracadabra works only with Netclipse 3.4.5"

  • When taking over I'd prefer to insist on having source code ready to build from command line

  • Also, in case if "they" use issue tracker for the project, I would do my best to squeeze all the data about these issues somehow (all issues in tracker, no matter fixed or not) - either by completely taking over that issue tracker with or by getting a read-only access to it or at least by getting a "snapshot" of it by whatever means.
     
    Information stored in an issue tracker might be a great help for maintainer

3 minor cosmetics
source | link

Source code in form ready to open in specified IDE

above, though nice to have, feels rather slippery - leaving too much room to fuss over IDE version, plugins, configuration. "oh by the way this will work only if you install and enable Habracadabra plugin v 6.6.6"

When taking over I'd prefer to insist on having source code ready to build from command line

  • Also, in case if "they" use issue tracker for the project, I would do my best to squeeze all the data about these issues somehow (all issues in tracker, no matter fixed or not) - either by completely taking over that issue tracker with or by getting a read-only access to it or at least by getting a "snapshot" of it by whatever means.
     
    Information stored in an issue tracker might be a great help for maintainer

    When taking over I'd prefer to insist on having source code ready to build from command line

  • Also, in case if "they" use issue tracker for the project, I would do my best to squeeze all the data about these issues somehow (all issues in tracker, no matter fixed or not) - either by completely taking over that issue tracker with or by getting a read-only access to it or at least by getting a "snapshot" of it by whatever means.
     
    Information stored in an issue tracker might be a great help for maintainer

Source code in form ready to open in specified IDE

above, though nice to have, feels rather slippery - leaving too much room to fuss over IDE version, plugins, configuration. "oh by the way this will work only if you install and enable Habracadabra plugin v 6.6.6"

When taking over I'd prefer to insist on having source code ready to build from command line

  • Also, in case if "they" use issue tracker for the project, I would do my best to squeeze all the data about these issues somehow (all issues in tracker, no matter fixed or not) - either by completely taking over that issue tracker with or by getting a read-only access to it or at least by getting a "snapshot" of it by whatever means.
     
    Information stored in an issue tracker might be a great help for maintainer

Source code in form ready to open in specified IDE

above, though nice to have, feels rather slippery - leaving too much room to fuss over IDE version, plugins, configuration. "oh by the way this will work only if you install and enable Habracadabra plugin v 6.6.6"

  • When taking over I'd prefer to insist on having source code ready to build from command line

  • Also, in case if "they" use issue tracker for the project, I would do my best to squeeze all the data about these issues somehow (all issues in tracker, no matter fixed or not) - either by completely taking over that issue tracker with or by getting a read-only access to it or at least by getting a "snapshot" of it by whatever means.
     
    Information stored in an issue tracker might be a great help for maintainer

2 Information stored in an issue tracker might be a great help for maintainer
source | link
1
source | link