Move DROID 7 requirements catalogue from wikispace to github

[d.ficht...@bgbm.org]

In September Wikispaces announced that it will no longer be offering free accounts to non-educational wikis [1]. So if one now wants to access the list of DROID 7 requirements that have been posted by the various stakeholders, the message "Subscription Expired" is shown [2]. Using the RSS-Feed [3] of the project it is possible to get the content of the first pages including the list of requirements (43 in total, see below) and the requirements 1-10. However, I assume that it is still possible for the account owners to export the content of the wiki. It would be useful to have these requirements be documented somewhere else, e.g. in the github issues list or the github wiki. This however has to be done by somebody who can export the content. I think it would be really helpful to have those requirements be again publicly available so others can see them, comment on them and add new ones.
This was just something I noticed and I wanted to express my thoughts here.
Cheers
  David


[1] http://blog.wikispaces.com/2014/09/wikispaces-is-no-longer-offering-free-non-education-wikis.html
[2] http://droid7.wikispaces.com/
[3] http://droid7.wikispaces.com/space/xmlo?teams=W11699932&v=rss_2_0

Requirements:
01. DROID Identifies multi-file format instances
02. DROID provides reporting on unidentified file formats
03. DROID provides a safe failure mode and resumes from point of failure
04. DROID contains mechanisms for format validation
05. DROID identifies attempts at data obfuscation (passwords / encryption / etc.)
06. DROID has a PREMIS compatible XML output
07. DROID provides machine readable XML output
08. DROID allows submission of unidentified formats and incorrect identifications via the user interface
09. DROID has a precise and 'fast' identification modes
10. DROID provides a clearer, more public API
11. DROID reports more comprehensive file level data information (Created/Modified/Last Accessed)
12. DROID can identify formats using the Java native regex library
13. DROID can identify text based formats such as source code and scripting languages
14. DROID interface reports on percentage complete when scanning
15. DROID identifies more container formats
16. DROID provides a database free mode for identification of formats without the need for profile reports
17. Where DROID comes up with multiple identifications for a single file, it displays these in an ordered way (most likely option at top)
18. DROID allows for the upload of container signature files
19. DROID 7 uses a different open source license
20. DROID 7 implements the concept of Fuzzy signatures
21. DROID scans DB/EDRMS BLOBS
22. The installation directory for DROID 7 is user configurable
23. DROID 7 scans PST files and reports on the format content of those files
24. DROID 7 report breakdown reports in configurable units (bytes/kb/mb etc.)
25. Drag and drop for files
26. DROID displays the signature file used per each profile tab
27. DROID supports the testing of local signatures
28. Signature files can be managed to be more modular and support local variations
29. DROID supports the local ignoring or overwriting of specific signatures
30. DROID remembers folder last scanned in folder structure
31. DROID Command line is easier to use
32. DROID identifies the creating application / environment of files
33. DROID is able to load a list of files to identify from a file
34. DROID Can generate a range of checksums for users
35. Folder metadata via Active Directory hooks into / from DROID
36. DROID better supports the development of new signatures
37. Plug-ins can be added to DROID
38. Ability to check against one fmt given from a partner through a local test
39. Add Bzip2ArchiveContentIdentifier
40. Having the possibility to get the FileFormat from a puid or a filename extension directly without "hacking" Droid internal data structures
41. Having the possibility to exclude x-fmt puid from answers
42. Mandatory match of signature and extension
43. DROID flags files that are part of analysed container files

[Dclipsham]

Hi David,

Yes, we exported everything before the closure. I agree that it will be useful to repost it in some form and we're exploring our options for this. Do you think Github is the most suitable place? I'm keen not to muddle the 'wishlist' with the bug reports and features under active development that currently seems to go on Github.

David

[ross-spencer]

I'm keen for the GitHub approach, as you can tag things quite nicely, and it's a good all round interface. Shouldn't be too difficult to maintain.

An alternative, however, might be Trello, and I know Richard Lehane, for example, uses that for Siegfried: https://trello.com/richardlehane

I'm not sure how good it is for community contribution though. Would need some investigation. 

Ross

[d.ficht...@bgbm.org]

I think GitHub is the best place to post the requirements. I can understand that those general ideas should not be confused with bugs in the general bug tracker, but as Ross already pointed out, with the tags it should be obvious which items are the general plans for version 7. Alternatively they could also be posted within the GitHub wiki, but this kind of lacks the generals features for issues in GitHub like commenting, crosslinking, etc. Also another advantage of GitHub as compared to other sides like Trello would be that it doen't require yet another account (assuming that more people have GitHub Accounts as compared to Trello and that Github is relevant for Droid development anyways, e.g. creating tickets for bugs or committing code/pull requests).
Therefore I think that GitHub is the best choice to have/collect/maintain the requirements for the next release.
Bye
  David

[Dclipsham]

Thanks David, Ross,

 

Ok there seems to be a consensus for GitHub. Resourcing issues make this difficult to achieve this side of the New Year, but we'll aim to reproduce the issues and comments raised, on GitHub, when we can. I'd expect early-mid January.

 

Graham Seaman, do you have anything to add at this stage, or are you content with the above?

 

David 

[Matt Palmer]

You could up a different GitHub repository - e.g. droid-future, with its own issue tracker for requirements, to avoid conflicts with bugs in the existing product.

Regards,

Matt.

[Graham Seaman]

That sounds like a good idea to me too - trying to separate definite requests or bug reports from general future requirements just using github tagging sounds like a recipe for confusion; using a separate repository would enable people to be fairly speculative about wishes for the future

 

Graham