Skip to content

Latest commit

 

History

History
79 lines (58 loc) · 3.8 KB

Creating-a-policy-radar.md

File metadata and controls

79 lines (58 loc) · 3.8 KB

Creating a policy radar in the GSF

This proposal is currently a work in progress - it’s shared to guide a discussion that should lead to us agreeing on an approach later in Q3/Q4 for allocating GSF sta resources to creating a policy radar.

This proposal outlines how we may go from an earlier accepted submission to create such a policy radar, to a minimal rst step that can be useful to members in the GSF.

The proposed solution as described in the proposal

The earlier proposal suggested what amounts to a forward looking calendar, that all members could consult, and ideally either submit suggestions themselves or make edits:

A collaborative, public view of coming policy events (consultations, new bills, laws being passed etc) in regions relevant to GSF members (essentially a collaborative, public calendar)

This was left intentionally open, to avoid prescribing any specic technology because at the time, we didn’t know what restrictions existed on tooling.

We also did not want to exclude members who can contribute knowledge, but might not be familiar with Github, source control or markdown formatting.

To be clear - a rst version of this could be as simple as a table listing the dates of various laws coming into eect, listed in in reverse chronological order, on a universally accessible website.

The complication

There are many well developed solutions for collaborating on structured data - examples like Notion, Conuence, and Outline exist.

However this is complicated by the following:

Licensing and permissions

One option might be to use commercial o the shelf software. Within a single organisation this is likely the default option. Across the members of the GSF, managing accounts is much more complicated.

Domain access

Some members are unable to access programs available on well known domains that might otherwise be used. Some of our members have Github’s domains blocked. Some of our members have Google’s domains blocked.

Varying skills and experience with default tools

Not everyone with policy experience relevant to green software is comfortable using github, markdown and other tools.

What should we do?

Create the simplest calendar possible, that can be viewed in a place accessible to current policy WG members, but can also be embedded elsewhere to get around the Google / Github domain issue.

One such example might be to maintain structured data in a repository of some kind, and present a view on this data on a dedicated page, on the new http://wiki.greensoftware.foundation website - which is accessible to all GSF members.

As long as the kinds of data laid out below can be stored, and returned in the required order, the kind of repository is not that important. Google sheets, a database - it doesn’t matter, as long as we can use other software to provide a view on the data to get around the banned domains issue.

Similarly, we’d provide a basic form to accept submissions from members who can not use Google, Github, or other banned software. Ideally have an automatic mechanism to add the submission to the structured data repository, but periodically, and manually reviewing submissions to add to the same structured data repository is also acceptable.

Our view is that the nal choice of technology should be down to the people implementing and maintaining the solution.

image

What information do we need to see?

To build a calendar we likely need a minimum of the following elds for data: image image

Appendix

https://www.perplexity.ai/search/new?q=pending&newFrontendContextUUID=b4e94701-4222- 4987-a1ce-b6ae9ecc5eaa