Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Parita Mathukiya
    @PremParita_gitlab
    107.Does your tool provide Does tool supports the requirement of authentication for preserving identity of the user by any mehtods like biometric, password, smart card, memorty card?
    108.Does your tool provide Does tool supports authorization requirement for allowing only authorized actors to perfrom CRUD (Create, Update, Read, Delete) operations on functional requirements?
    109.Does your tool provide Tool shall support the requirement for implementing pseudonymity for the system (singly proxy method, onion routing, crowd or any pseudonymizer tool)?
    110.Does your tool provide Does tool supports facility of giving individual or collective pseudonyms for perfomring opertions on requirement?
    111.Does your tool provide Does tool support unlinkability and unobservability of requirements with facility of spyware detection removal, broswer cleaning eraser, activity traces eraser)?
    112.Does your tool provide Does tool supports privacy requirements like privacy policy management?
    113.Does your tool provide Does tool supports anonymuous user login?
    114.Does your tool provide Tool shall support the pseudonym remailers for hiding the source identiy?
    115.Does your tool provide Privacy policy questions for framing privacy policy of the website for the project of type web app or website?
    Jace Browning
    @jacebrowning
    Doorstop handles 51, 52, 53, 54, 57, 58, 59
    Jace Browning
    @jacebrowning
    @PremParita_gitlab Would you mind posting this whole list as a GitHub issue using the “Task List”/checkbox format? It will be easier for me to check off items that way.
    Parita Mathukiya
    @PremParita_gitlab
    thank you so much
    Romain Taprest
    @RomainTT
    Hi !
    Does anyone have a public example of a complex doorstop project ? I would like to see what it looks like when it is used seriously
    Also, a quick question: is it not annoying that when we type doorstop add SRS it creates a file but does not open the editor to edit the file immediatly ? One must create the file, then open it manually in an editor
    Jace Browning
    @jacebrowning
    Someone could add an '--edit' option to the 'add' command
    Romain Taprest
    @RomainTT
    You’re sooo fast to accept that PR
    Jace Browning
    @jacebrowning
    :smile:
    Jace Browning
    @jacebrowning
    Would anyone like to help review PRs on GitHub? I’m still happy to make releases, but I don’t have the bandwidth for code reviews.
    Romain Taprest
    @RomainTT
    As long as it does not requires a super-expertise in doorstop code, I would be happy to do it. I can at least check if it works, check consistency, and ban ugly code :)
    But if you want someone who dug deep into your code I'm not the one :(
    Jace Browning
    @jacebrowning
    @RomainTT Thanks! I added you as a collaborator which should give you permission to approve PRs.
    Romain Taprest
    @RomainTT
    Thanks! I am registered as a contributor but it seems I can’t approve PR yet.
    Maybe a reviewer list configuration ?
    Question about your milestones: what’s the use of "current" ? because there are no closed issues in "1.6" but many in "current", I find that confusing…
    Jace Browning
    @jacebrowning
    Are you seeing any error when attempting to review a PR? Collaborators should have that permission: https://help.github.com/en/articles/permission-levels-for-a-user-account-repository
    I’m open to suggestions on project management. I was using milestones (before GitHub projects existed) like so:
    • v<next>: Work that is required before the next release
    • current: Work that is well-defined and ready to be worked on
    • backlog: Work that requires convincing and/or more details
    Romain Taprest
    @RomainTT
    Sorry, I had to assign the review to myself before being able to do it. I understand now ! The truth is I’m more used to Gitlab :P
    Romain Taprest
    @RomainTT
    Concerning project management, I think every valid issue ("ready") should target a future release and therefore be placed in a v<next> release. I think it is better to shift issues from versions to versions if the time is too short rather than letting them in a temporary milestone ("current") forever.
    Jace Browning
    @jacebrowning
    That makes sense to me. I think there should also be a v<future> milestone (v2.0 in this case) for valid, but breaking changes
    Luca
    @sevendays
    Hi. I'm evaluating doorstop for an automotive project. So far so good, the only thing I'm missing is a way to display an additional parameter "ASIL X" in the published documents. I tried the beta "header" feature but I'd actually like to perform some checks on the additional parameter too.
    e.g. system requirements are assigned an ASIL grade SysReqXXX ASIL D, then children requirements should either match the ASIL grade HwReqXXX ASIL D or a lower ASIL with the original one between parentheses HwReqXXX ASIL C(D)
    Having passed the checks, I would like the published requirement to have the format: 1.0 HwReqXXX ASIL C(D)\n <requirement text>
    Luca
    @sevendays
    right now it's doing: 1.0 ASIL C(D) <small>HwReqXXX</small>
    Luca
    @sevendays
    well, further attempts: I noticed that doorstop will happily import any custom column in the CSV, which is really nice!
    however, it will not import the header column, which prevents me from having the custom attribute displayed somewhere when publishing docs
    Luca
    @sevendays
    There is a bug in doorstop-gui: if the requirement is edited in the text, the ASIL extended attribute is silently cleared. I think it has to do with the fact that the ASIL attribute was not a MD text, but a single string ("QM", "A", "B", "C" and "D")
    Justin Waring
    @JustinW80
    Just a quick line to say I'm happy to see lots of activity in this project lately.
    Thanks to all the contributors!
    Paul Adamson
    @padamson
    I'm evaluating doorstop for a software and a hardware project. Any other interest out there in risk management within doorstop?
    Luca
    @sevendays
    I resorted to simple python scripts pulling out the csv and parsing that, since it is more generic and applicable to the output of other RM tools too
    the gui shall not be used
    Jace Browning
    @jacebrowning
    FYI, I’m going to release what we have right now as v1.6
    Adrian
    @tangoalx
    hmmm... did something elementary changed with v1.6? I tried now to create a new document with $ doorstop create SRD ./reqs/srd, but it says that there is no root document.
    exact error message is:
    building tree...
    ERROR: no root document
    Adrian
    @tangoalx
    Do I miss something?
    Jace Browning
    @jacebrowning
    Hmm, the same command works for me. Does adding -vv reveal anything helpful?
    Adrian
    @tangoalx
    yes, the -vv is helpful. I have a python virtual environment and it looks like the tutorial documents are found, too. As there is no common root document of the tutorial documents and my new document to be created, this error arises. I don't know yet how to fix it, but this is the reason
    A possible fix is to doorstop create SRD ./reqs/srd -j .. However, I just still wonder why it is a problem with v1.6, but not with v1.5.
    Adrian
    @tangoalx
    Ok, it is because I installed pythons virtual environment in the same root directory... installing it elsewhere, solves the problem
    Jace Browning
    @jacebrowning
    The new chat room is here: https://gitter.im/doorstop-dev/community