Wiegand v. One World Foods. Inc

Filing 61

ORDER re 51 Discovery Dispute Conference: Approved ESI Protocol. Signed by Magistrate Judge Donald G. Wilkerson on 9/6/2017. (sgp)

IN THE UNITED STATES DISTRICT COURT
SOUTHERN DISTRICT OF ILLINOIS
LARRY WIEGAND and TIMOTHY
BLANKENSHIP on behalf of themselves
and all others similarly situated,
Plaintiffs,
v.
ONE WORLD FOODS, INC. d/b/a
STUBB’S LEGENDARY BAR-B-Q,
Defendant.

)
)
)
)
)
)
)
)
)
)
)
)

No. 3:16-cv-01168-MJR-DGW

STIPULATION AND ORDER REGARDING THE PRODUCTION OF
ELECTRONICALLY STORED INFORMATION AND HARD COPY DOCUMENTS
THIS MATTER having been presented to the Court on consent of the parties, and for
good cause shown;
IT IS ON THIS 6th day of September, 2017;
ORDERED that all parties’ productions in this matter shall be in accordance with the
following protocol:
I.

GENERAL PROVISIONS AND SCOPE:
A.

The Order streamlines ESI production to promote a “just, speedy, and inexpensive

determination” of this action, as required by Rule 1 of the Federal Rules of Civil Procedure. The
procedures and protocols set forth in this Order shall govern the production format of hard-copy
documents and ESI in this action, to the extent available. The Parties reserve all rights and
objections under the Federal Rules of Civil Procedure for matters relating to the production of
ESI or hard-copy documents that are not specifically addressed in this Order.
B.

This Order may be modified for good cause. The Parties may agree to

modification without application to the Court. To be effective any modification must be in
writing and signed by counsel for both Parties. If the Parties cannot reach an agreement regarding
Page 1 of 15

proposed modifications, the Parties shall submit their competing proposals and a summary of
their dispute to the Court, or comply with any other procedure ordered by the Court.
II.

PRESERVATION AND COLLECTION:
A.

The Parties acknowledge their ongoing responsibility to preserve potentially

responsive ESI and hard-copy documents, and they agree that the preservation of potentially
relevant ESI and hard-copy documents will be reasonable.
B.

There is no need to preserve or collect ESI from the following sources, which are

deemed not likely to contain relevant information and not to be reasonably accessible:
1.

Random access memory (RAM), temporary files, or other ephemeral data
that are difficult to preserve without disabling the operating system;

2.

On-line access data such as temporary internet files, history, cache,
cookies, and the like;

3.

Voice-mail messages; imessages, text messages and similar ephemeral
data on personal devices that no longer exist on such devices;

4.

Back-up data that is substantially duplicative of data that are more easily
accessible elsewhere;

5.

Server, system, or network logs; and

6.

Data remaining from systems no longer in use that are unintelligible on the
systems in use.

C.

No Party is obligated to preserve hardware on which data that is required to be

preserved resides, so long as such data and associated metadata has first been imaged or
otherwise preserved in an accessible form on another hardware device.
D.

The Parties shall preserve e-mail communications, including all associated

metadata and associated attachments relevant to claims or defenses in this action (1) by
Page 2 of 15

maintaining such e-mail files on a server or within an electronic archive that is not subject to a
deletion schedule, or (2) by creating an electronic snapshot of implicated e-mail on servers.
E.

The Parties shall preserve data relevant to claims or defenses and held in databases

(1) by maintaining such data in accessible electronic systems that are not subject to a deletion
schedule, or (2) by creating an electronic snapshot of relevant database servers or an export of
relevant data on database servers.
F.

Where electronic documents relevant to claims or defenses in this action and

located in shared or home directories (e.g., loose files such as word-processing documents, Excel
spreadsheets, and PowerPoint presentations) are subject to a deletion schedule, the Parties shall
preserve such documents by (1) maintaining such directories and files contained therein in
accessible electronic systems that are not subject to a deletion schedule, or (2) by creating a
forensically sound backup of relevant shared drive or home directory servers.
III.

PRODUCTION OF HARD-COPY DOCUMENTS
The format of productions of hard-copy documents shall comply with the following

requirements:
A.

IMAGE FORMAT. Documents that exist in hard-copy format shall be scanned

and produced as single page black and white PDF files or Group IV TIFFs created with a
resolution of at least 300 dots per inch (“dpi”). Color documents may in .JPG format in lieu of
TIFF images; color .JPG files shall also be provided with a resolution of at least 300 dpi. Each
TIFF or .JPG image shall be branded with sequential production number and appropriate
confidentiality designations. Each TIFF or .JPG image filename shall correspond to the Bates
number associated with that page. TIFF or .JPG files shall show all text and images that would be
visible to a user of the hard-copy document. Producing such hard-copy documents in such
formats does not change their character from hard-copy documents into ESI.
B.

DATABASE LOAD FILES/CROSS-REFERENCE FILES. A production

should be provided with (a) an ASCII delimited data file (“.dat”) using Concordance default

Page 3 of 15

delimiters, and (b) an Opticon (Concordance Image) image load file (“.opt”) that can be loaded
into Concordance version 8 or above. In addition:
1.

The total number of documents referenced in a production’s data load file
should match the total number of designated document breaks in the Image
Load file(s) in the production.

2.

The Opticon file should provide the beginning and ending Bates number of
each document and number of pages it comprises. Each TIFF in a
production must be referenced in the corresponding image load file.

3.

In addition to the metadata fields identified for production in Section IV.C
below, each .dat file shall include links to multi-page (document level) text
files (“Text Path”).

C.

OCR TEXT FILES. A commercially acceptable technology for optical character

recognition (“OCR”) shall be used for all scanned, hard-copy documents. The filename for the
multipage text file described above in Section III.B.3 shall correspond to the beginning Bates
number of the document. If the document is redacted, the text file shall not contain the redacted
portions of the documents, but shall contain the remaining unredacted text.
D.

METADATA. The following fields, which are defined in Appendix A, shall be

produced in the .dat file accompanying hard-copy documents: (a) BEGBATES, (b) ENDBATES,
(c) BEGATTACH, (d) ENDATTACH, (e) PAGE COUNT, (f) CUSTODIAN, (g) RECORD
TYPE, (h) CONFIDENTIAL DESIG, and (i) REDACTION.
E.

UNITIZING OF DOCUMENTS. In hard-copy documents, distinct documents

shall not be merged into a single record, and single documents shall be not be split into multiple
records (i.e., hard-copy documents should be logically unitized). The Parties shall use reasonable
efforts to unitize documents correctly to avoid producing large numbers of documents in a single
“clump.”
IV.

PRODUCTION OF ESI:
A.

FILTERING.
Page 4 of 15

1.

Electronic file collections will be De-NISTed, removing commercially available
operating system and application file information contained on the current NIST
file list. Additional filtering of system file types based on file extension may
include, but are not limited to: WINNT, LOGS, DRVS, C++ Program File (c),
C++ Builder 6 (cpp), Channel Definition Format (cdf), Creatures Object Sources
(cos), Dictionary file (dic), Executable (exe), Hypertext Cascading Style Sheet
(css), JavaScript Source Code (js), Label Pro Data File (IPD), Office Data File
(NICK), Office Profile Settings (ops), Outlook Rules Wizard File (rwz), Scrap
Object, System File (dll), Temporary File (tmp), Windows Error Dump (dmp),
Windows Media Player Skin Package (wmz), Windows NT/2000 Event View Log
file (evt), Python Script files (.py, .pyc, .pud, .pyw), and Program Installers.

2.

The Parties shall filter out stand-alone files identified as zero-bytes in size.

3.

The Parties may limit processing of discoverable information to that which was
created, modified, sent, or received between certain dates as agreed by the Parties,
or set forth by the Court. Container files such as (.zip, .rar or .tar files) will be
processed such that their contents may be reviewed individually.

B.

STRUCTURED DATA. Data that is stored in a database, whether maintained

internally by the Party or through a third party provider, shall, when reasonably possible, be
produced as reports in Microsoft Excel, Microsoft Access or ASCII delimited text format.
C.

PRODUCTION FORMAT FOR ESI.

1.

Image Format. With the exception of the documents discussed in section IV.C.6
below, all ESI documents shall be produced as single page black and white Group
IV TIFFs, created with a resolution of at least 300 dpi. Color documents may be
produced in .JPG format in lieu of TIFF images color .JPG files should also be
provided with a resolution of at least 300 dpi. Each TIFF or .JPG image shall be
branded with sequential production numbers and appropriate confidentiality
designations. Each TIFF or .JPG image filename shall correspond to the Bates
Page 5 of 15

number associated with that page. TIFF or .JPG files shall show all text and
images that would be visible to a user of the ESI documents in native format.
Thus, for example notes and redlines or comparisons in documents (i.e.,
Microsoft Word notes and redlines) shall be processed with all markings and
hidden text unhidden and to show the author for the edits and comments on the
TIFF of .JPG image.
2.

Numbering/Endorsement. Every produced document will have a unique Bates
number assigned, regardless of the format of the documents. The Bates number
prefix will be generated so as to identify the producing party. For documents
produced in TIF image format, including slipsheet images for natively-produced
files, each TIFF image will have a legible Bates number as a unique page
identifier electronically “burned” onto the image at a location that does not
obliterate or obscure any information from the source document. Files produced
in native format shall be named by corresponding Bates number with
confidentiality designation (e.g., BATES00000010_CONFIDENTAL.xlsx); if the
file does not have a confidentiality designation then only the bates number needs
to be used (e.g., BATES00000010.xlsx) . A producing party should be consistent
in the Bates number prefixes it uses across its productions. Document families
shall be produced consecutively, noting family relationships in the appropriate
metadata fields. In the case of materials deemed confidential in accordance with
any applicable federal, state, or common law, or any protective order or
confidentiality stipulation entered into by the Parties, a confidentiality
designation may be “burned” onto the document’s image at a location that does
not obliterate or obscure any information from the source document.

3.

Metadata. For email, the Parties shall provide the applicable email metadata fields
outlined in Appendix A hereto and associated with each document produced, to
the extent they are reasonably available from the source of collection. For
Page 6 of 15

email attachments and non-email electronic documents (standalone, loose native
files), the Parties shall provide the applicable non-email ESI metadata fields
outlined in Appendix A hereto and associated with each electronic document
produced, to the extent they are reasonably available from the source of
collection. For hard copy documents, the Parties shall provide the applicable
metadata fields associated with hard copy outlined in Appendix A. All metadata
referenced in Appendix A shall be provided in a delimited (.dat) file with the field
headers as the first row.
Format of .dat file delimeters:
Column - ASCII 020
Quote - ASCII 254
Newline - ASCII 174
Multi-Value - ASCII 059
4.

Image Cross Reference. A standard Opticon (.OPT) file will be provided with
each production that contains document boundaries.
a)

Format:

<Bates Number>,<Volume Name >,<Relative Path to TIF Image>,<Y if First Page of
Document,
Else Blank>,,,<If First Page of Document, Total Page Count>
b)

Example:

BATES000000001,VOL001,\IMAGES\001\BATES00000001.TIF,Y,,,,2
BATES000000002, VOL001,\IMAGES\001\BATES00000002.TIF,Y,,,,
BATES000000003, VOL001,\IMAGES\001\BATES00000003.TIF,Y,,,,1
5.

Text. Document level text files (.TXT) will be provided for each document

produced. Text files will be named the first Bates number of the respective document. Extracted

Page 7 of 15

text will be provided when it exists for non-redacted documents. OCR Text will be provided for
documents when no extracted text exists or when the document is redacted.
6.

Native Files. Subject to section VIII below regarding redactions, any file produced

in native format should be produced with a link in the Nativelink field, along with extracted full
text and all applicable and reasonably available metadata fields set forth in Appendix A to the
extent doing so is feasible. Any file produced in native format should be named to match the
beginning Bates number of their corresponding entries in the database load files. Additionally,
every file produced natively should be accompanied by a Bates-stamped and confidentialitystamped TIFF placeholder indicating the document was provided in native format.
a)

Spreadsheets. Spreadsheets shall be produced in native format, with TIFF
placeholders and available metadata provided in database load files, unless they
are redacted, in which case they shall be produced as TIFF images. In addition to
the requirements laid out in section IV.C.6 above, native copies of all spreadsheets
(unless redacted) shall be produced with extracted full text and all applicable and
reasonably available metadata fields set forth in Appendix A.

b)

Presentation Files. Presentations shall be produced in native format, with TIFF
placeholders and available metadata provided in database load files, unless they
are redacted, in which case they shall be produced as TIFF images. In addition to
the requirements laid out in section IV.C.6 above, native copies of all
presentations (unless redacted) shall be produced with extracted full text and all
applicable and reasonably available metadata fields set forth in Appendix A.

c)

Video & Audio Files. Audio and Video files shall be produced in native format,
with TIFF placeholders and available metadata provided in database load files.

d)

Request for Additional Native Files. If a Party reasonably concludes that
production in native format of any document(s) is necessary (e.g., to decipher the
complete meaning, context, or content; to determine if there is any relevant
“hidden text” in the document; to determine if there is any important use of color
Page 8 of 15

in the document, etc.), such Party may request production of the original
document in native format, which request shall not unreasonably be denied. The
Parties agree to meet and confer in good faith with respect to any such request.
The producing Party may decide that a reasonable basis exists to produce
additional file types among its own collection in native format and may do so after
notifying the receiving Party. Any native files that are produced should be
produced with a link in the Nativelink field, along with all extracted text and
applicable metadata fields, as well as a Bates-stamped and confidentiality-stamped
TIFF placeholder.
D.

PRESUMPTION OF AUTHENTICITY: The Parties agree, without waiving

any other objections as to admissibility, that all ESI produced in discovery by the Parties are
presumed to be authentic for purposes of this lawsuit only, absent a showing that the document is
not what the proponent claims it to be.
V.

THIRD PARTIES:
A.

A party that issues a non-party subpoena (the “Issuing Party”) shall include a copy

of the Order with the subpoena and request that third parties produce data and documents in
accordance with the specifications set forth herein.
B.

Nothing in the Order is intended or should be interpreted as narrowing, expanding,

or otherwise affecting the rights of third parties to object to a subpoena.
C.

The Issuing Party is responsible for producing any documents obtained under a

subpoena to the other party.
D.

If the Issuing Party receives any hard-copy documents or native files, the Issuing

Party will process the documents in accordance with the provisions of the Order, and then
produce the processed documents to the other party.
E.

If the non-party production is not Bates-stamped, the Issuing Party will apply

unique prefixes for the non-party production and Bates numbers prior to producing them to all
the other Parties.
Page 9 of 15

VI.

PRODUCTION MEDIA: The production data may be exchanged between counsel in

encrypted form (e.g., TrueCrypt, password-protected Zip, or RAR files). Productions of 10 or
fewer GB may be made via FTP or secure server; larger productions should be made on hard
media (e.g., hard drives). Each production shall be provided in the following folder structure:
A.

Top-level folder: This folder will indicate the production volume;

B.

Sub folders;
1.

IMAGES: This folder will contain multiple sub-folders with only TIFF and
.JPG files in them. No other type of file should reside in the “IMAGES”
folder. Sub-folders shall not contain more than 5,000 images per folder.

2.

TEXT: This folder will contain the full text files in UNICODE, UTF8 or
ANSI format in a separate folder labeled TEXT. Subfolders shall not
contain more than 1,000 text files per folder.

3.

DATA: This folder will contain load files compatible with Concordance
version 8 or above and Opticon.

4.

NATIVES: This folder will contain native files. Sub-folders shall not
contain more than 1000 native files per folder.

VII.

PRIVILEGE:
A.

The Parties shall produce privilege logs following each production. The privilege

logs shall contain the following information:
1.

Bates Begin;

2.

Bates End;

3.

Bates Begin Attach;

4.

Bates End Attach;

5.

Custodian;

6.

Privilege Claim (e.g., WP, AC);

7.

Email To;

8.

Email From;
Page 10 of 15

9.
10.

Email BCC;

11.

Date Sent or Date Created; and

12.
B.

Email CC;

Description of Nature of Document.

The Parties shall identify on their logs where counsel is present in conversation,

specifically for columns A(7) through A(10) noted above. Where the presence of counsel forming
the basis of the privilege is not readily ascertainable from columns A(7) through A(10) above, the
Parties shall include a reference to counsel in the description filed described in A(12) above.
C.

Privileged communications between Parties and their counsel regarding the above

captioned actions, including any pre-complaint investigation need not be placed on a privilege
log. The Parties may agree to other communications that need not be logged.
D.

With respect to email chains (i.e., documents that reflect multiple, distinct emails),

the Parties agree that: (i) the Parties will not withhold from production non-privileged,
substantive portions of email strings; (ii) the Parties’ privilege logs need not contain separate log
lines for individual emails within a single email chain that is logged; and (iii) the Parties’
privilege logs need not contain separate log lines for emails that are otherwise logged as part of
an email chain.
VIII. REDACTIONS:
A.

REDACTIONS. In the event that a document or ESI requires redaction the

Parties agree that the native version need not be produced in the first instance, full text may be
replaced with OCR text that excludes the redacted material, and metadata fields may be excluded
if they contain material redacted for privilege. The TIFF image should show the word “redacted”
where applicable and a production Load File field should be populated to indicate the document
contains a redaction. If a document to be produced in native format contains information that
would otherwise be subject to redaction - e.g., on the basis of privilege or work product
protection - the document may be produced by producing the document either in redacted and/or
excerpted TIFF format, or in redacted and/or excerpted native format, in the producing Party’s
Page 11 of 15

discretion, and to the extent reasonably and technically possible. If a Party reasonably concludes
that production in native format of any redacted document(s) initially produced in TIFF format is
necessary (e.g., to make the a document, including any spreadsheet of presentation readable, to
decipher the complete meaning, context, or content, to determine if there is any relevant “hidden
text” in the document, to determine if there is any important use of color in the document, etc.),
such Party may request, with the understanding that relevant portions of native files to be
replaced with “[REDACTED]” or a similar mark as necessary, the production of the original
document in native format, which request shall not unreasonably be denied. The Parties agree to
meet and confer in good faith with respect to any such request.
IX.

DISPUTE RESOLUTION: The parties shall meet and confer in good faith on any issue

related to ESI or hard-copy document discovery prior to submitting any dispute to the Court.
IT IS SO ORDERED.
DATED: September 6, 2017

DONALD G. WILKERSON
United States Magistrate Judge

Page 12 of 15

APPENDIX A: REQUIRED METADATA FIELDS

Field

Description

Attachment
Email Or Loose
Native File

TITLE

First bates number assigned to
the first page of the document
Last bates number assigned to
the last page of the document
First bates number assigned to
the first document in a family
Last bates number assigned to
the last document in a family
Number of images provided
for the document
Individual/Source assigned to
the record at collection time,
formatted as Last Name First
Native file property Title

SUBJECT

Native file property Subject

X

DATE
CREATED

Date created as extracted from
original file (MM/DD/YYYY)

Hard
Copy

X

BEGBATES
ENDBATES
BEGATTACH
ENDATTACH
PAGE COUNT
CUSTODIAN

TIME CREATED Time created as extracted
from original file (24 HR)
Date last modified as
DATE LAST
extracted from original file
MODIFIED
(MM/DD/YYYY)
[Normalized to GMT]
Time last modified as
TIME LAST
extracted from original file
MODIFIED
(24 HR) [Normalized to
Type of file (e.g. EMAIL
RECORD TYPE ITEM, ATTACHMENT,
LOOSE FILE, E-DOC,
Page 13 of 15

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X
X

X

X

Field

Description

Attachment
Email Or Loose
Native File

FILE NAME

Name of file as it appeared
when collected.

X

FILE
EXTENSION

Extension of the native file.

X

FILE SIZE

Size of the native file, in bytes

Hard
Copy

X

FOLDER PATH
EMAIL FROM
EMAIL CC
EMAIL BCC
EMAIL TO
EMAIL DATE
SENT
EMAIL TIME
SENT
EMAIL DATE
RECEIVED
EMAIL TIME
RECEIVED
EMAIL
SUBJECT
TEXT LINK

Original folder path to file
when collected (if loose native
file) or folder path to
il/ l d it
ithi
Email FROM value (Email
Author)
Email CC value (Email
Copyee)
Email BCC value (Email
Blind Copyee)
Email TO value (Email
Author)
Date email sent
(MM/DD/YYYY)
Time email sent (24 HR)
[Normalized to GMT]
Date email received
(MM/DD/YYYY)
Time email received (24 HR)
[Normalized to GMT]

X
X
X
X
X
X
X
X
X

Email Subject value

X

Relative path to the document
level text file (e.g.
\TEXT\001\BATES00000000
1.TXT)

X

Page 14 of 15

X

X

Field

Description

NATIVE LINK

Relative path to native file (if
produced). (.e.g.
\NATIVES\001\BATES00000
0001.XLS)

MD5_HASH

MD5 hash value of native file

Attachment
Email Or Loose
Native File

CONFIDENTIAL Confidentiality designation
DESIG
Yes/No field indicating
REDACTION
whether or not document is

Page 15 of 15

Hard
Copy

X

X

X

X

X

X

X

X

X