IEEE.org     |     IEEE Xplore Digital Library     |     IEEE Standards     |     IEEE Spectrum     |     More Sites

outline.md 11 KB
Newer Older
Joshua Gay's avatar
Joshua Gay committed
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
## Quick Start

### Who is needs to read the Maintainers Manual? 

:pushpin: Maintainers and Leads of an IEEE Open Source Projects shall (**must**) follow all requirements contained in this manual. 

All other users of the IEEE Open Source Platform should follow recommendations and the recommended templates and may benefit from the examples and suggestions throughout. 



### What are the requirements?

:bulb: Click on the "▸" and expand the section. Click again to collapse.  :bulb:

<details>
  <summary>Click to expand!</summary>
  
  ## Heading
  1. A numbered
  2. list
     * With some
     * Sub bullets
</details>

### About IEEE 
* IEEE is the world’s largest technical professional organization dedicated to advancing technology for the benefit of humanity.
  * Mission: IEEE's core purpose is to foster technological innovation and excellence for the benefit of humanity.
  * Vision: IEEE will be essential to the global technical community and to technical professionals everywhere, and be universally recognized for the contributions of technology and of technical professionals in improving global conditions.




* 
* This Maintainers Manual is approved by the Open Source Committee of the IEEE SA Board of Governors.

as well as recommendations, and guides fo 

* The *Maintainers Manual*  contains requirements ("shalls"/"musts"), recommendations ("shoulds"), and , and suggestionsguidelines and advice for someone who is the maintainer This is the the *Maintainers Manual* for IEEE Standards Association Open Source 

  * policy requirements for leads and maintainers





## Introduction

Whether you are a person downloading a socail app to your phone, a
developer building on top of the next great aschynchronous runtime
library, or a maker bringing a design document to fabrication of your
new IoT gizmo, in each situation, you will almost always be able to
determine quickly and unambiguously whether or not a self-contained
(single-sourced) app, library, or design document you have downloaded
is an open source work. In practice, you can tell if something is an
open source work by simply checking to see if the source code and/or
design documents are made available to you under the terms of an open
source license.

However, the matter can quickly get complex  

However, when you are helping to create open source software and
hardware, or you are seeking ot provide support and guidance for the
growth of many new open source communities, a more general definition
to go alongside the licensing terms is essential. The IEEE Standards
Association Open Source Committee Operations Manual provides the
following definition of open source for use by our communities:


> **Open Source** is a digital work for which the human-readable
> source code is available—in the preferred form for making
> modifications—for use, study, re-use, modification, enhancement, and
> re-distribution by the users. Open Source applies to software and
> hardware, which may include computer code, hardware designs, data,
> documentation, documents, and other digital objects.


However, when it comes to nurturing, growing, and sustaining open
source projects, communities, and ecosystems, then open source
software & hardware is more than just licensed source code files, it
is also: open source is also project planning and management; is also
project management, and governance; it is massively distributed,
collaborative development; it is shipping a product to users or
adopters of your work and developing a trusted relationship with them.

The IEEE SA provides a platform of 

As a user of opensource.ieee.org, we have granted to you the ability to be If you are a Lead or Maintainer of a project hosted on [opensource.ieee.org](https://opensource.ieee.org), 

Similarly, the IEEE SA offers a platform for users, contributors,  support for communities to come and collaborate  open source, and so we too are seeking to 

As a Lead or Maintainer of a project hosted on the <https://opensource.ieee.org>,  it is essential that you follow

For Leads and Maintainers of open source projects, eaders and maintainers of open source projects, it is often about
fostering a community of users and contributors.

The purpose of this manual is to:

* 

If you are (or are thinking of becoming) a Lead or a Maintainer of an
open source project hosted on <https://opensource.ieee.org>, then this
manual is required reading. Wherever possible we will do our best to
indicate clearly any requirements we ask you to follow (we will use
terms such as "shall" and "must").


### Contents

This is  copy of our internal open source documentation, with a few
exceptions. For a number of reasons, we can't share everything, so you
might find places where a link is missing or some content had to be
removed.

Aside from those few cases, this is the same documentation seen by
Google employees. As a result, there is some Google lingo throughout,
as well as references to internal tools and systems. See the glossary
for definitions of some of the most common ones.

There are three primary sections of the docs:

Creating covers how Googlers release code that they've written, either
in the form of a new standalone project or as a patch to an external
project. The same process is used for small 20% projects and full
blown Google projects.

Using explains how we bring open source code into the company and use
it to help build great products. We carefully catalog thousands of
packages to help us maintain license compliance.

Growing describes some of the programs we run inside and outside the
company to support open source communities.

Who this is for

### 


### About IEEE SA Open Source  







## Contributors (“engineers”)

IEEE Public (e.g. companies wanting to know how the platform is governed and works …)

### Front Matter and intro

### Scope and Purpose of the Manual

Executive summary .5 page.


* The role and responsibility of the maintainer in the IEEE Open Source environment
* Who needs this (maintainers of group and individual projects)
* Scope & Purpose statement - to document roles and responsibilities and applicable policies.

### Scope and Purpose of the Platform


* Positioning: IEEE Open as a philosophy [Link to Marketing Materials when available, not a blocker] [
* Types of IEEE Open Source Projects [Include and explain]
* Supporting the wider open source community [ included in marketing, not a blocker]
  * Access to technical expertise
  * Open Source planning, dev, testing, communication tools
* Supporting open consensus standards that incorporate open source [Merge with descriptions of types of projects above]
  * Software
  * Hardware
  * Entire standard as open source 

Resources for Maintainers


* Community / IP manager
* Platform resources
* Issue reporting 
* (Continuous integration)
* (Peer Review mention)

#### IEEE Open Source Governance

[Roles and responsibilities are in previous section]

[Details are in following sections]

[Governance documents have already been agreed]

Summary of how IEEE governs Open Source

Creating a governance document (see Ops Man 5.1.2 for what needs to be covered)

Samples / Templates… TBD (Group / Official / Standards)

### Account and Group Management

(May separate out things only applicable to group namespaces)

Cross-reference table (individual / group / official / standards)


* Adding users to a project
* Assigning project roles to users
* Granting access
* Creating a project- approvals (if needed)
* Name, description, README file
* LICENSE (choose Apache 2.0 or BSD 3-clause)
* Collaboration responsibilities
* Have fun! glhf
* Responsibilities when you fork a project
* Mattermost / Slack
* List of governance documents

Publicizing your project [ Not clear where this goes but we want to tell maintainers how to access resources for publicizing projects]

### Running a project

* What Leaders and Committers do [links to appropriate policy documents]
* Responsibilities of Maintainers
  * Following policies and procedures
    * Following additional IEEE agreements (standards, fiscal sponsorship, etc)
    * Representing your project and the IEEE outside of the Platform
  * Delegating responsibility and access control
  * Communicating with OSCM, OSCom, IPR Manager
  * Community governance
  * Leadership changes
* Configuration Management
  * Version control, version (semantic) numbering *within your own project* [once forked, new maintainer - could by you], submodules
* Validation, scanning, and enforcement of CLAs (e.g. responding to alerts) [understanding what they must do to maintain legal notices etc.]
* (later) Peer review and testing -- notice that it is planned, link to OSCom OpsMan
  * Aim of peer review 
  * under development (SIG needed)

[Maybe under release management]

* Release Management
  * Mandatory coordination with OSCM
  * Official vs unofficial releases [official projects shall designate which releases are official] [blocking issue]
  * Signed releases (PGP signing) [should not block MVM]
  * Backport (and security) patching [should not block MVM]
  * Mirroring and archiving releases  [should not block MVM]
  * Documentation requirements for open source that is incorporated into standards (including short description of what the software does, how to install it, plus stuff Josh said.)
* Issue problem management 
  * Creating, assigning, tagging, and managing issues [IT IS REQUIRED THAT MAINTAINERS RESPOND TO SOME TYPES OF ISSUES]
  * Email/helpdesk use of issues  [should not block MVM]
* Standards considerations 
  * Roles and responsibility of Standards Committee and WG with OS project - [covered in SASB Ops Man so summarize and link]
  * Balloting (see process points document) [covered in SASB Ops Man so summarize and link, need to explain the workflow and how it works]
    * Comment resolution group
    * Comments made as issues versus ballot comments 
    * Ballot comments that address open source artifacts (e.g. code) - c.f. The need for a CLA
  * Notices [Required notice that it is not an approved standard in the read.me file]
  * Interactions with WG (copy/paste other WG guidance?)

### Retiring a group or project [put in, but not a blocker]

* Update README file and CONTRIBUTING/GOVERNANCE files
* Archive project (or request that OSCM archives project)
* Retiring a group requires agreement among all leadership and approval by IEEE Staff 
  * Email OSCM
* Special considerations for standards projects

### Licensing policies [blocker]

* CLAs and choice of license
* Use of third-party material and dependency management 
* Naming, Branding, Trademark, and Tradename

### Security policies [next]

* Minimum requirements:
  * Official IEEE Open Source Projects (including standards that incorporate Official IEEE Open Source Projects) _may_ be required to follow our Security policy?
  * IEEE Open Source Projects are able to opt-in 
* Responsibilities under policies 
* Release and CVE
* Notice that the IEEE may scan all repositories on the IEEE Open Source Platform?

Shall have SVE process for official releases of official / standards projects

Should have SVE process for group projects

May have for individual