You are browsing the archive for Our Work.

WANTED: Open Knowledge Foundation seeks visionary leader to steer the world towards a free, fair, and open society

Vanessa Barnett - July 9, 2020 in Featured, Join us, News, Open Knowledge Foundation, Our Work

You are a charismatic, innovative champion of openness, and a strategist with leadership skills and experience of engaging highly motivated teams and funders. We are the Open Knowledge Foundation, building a better future where knowledge is shared so all can live happier and healthier lives. Together, we will spread the global message of openness and establish new rules to counter the unaccountable tech companies monopolising the digital age. We will tear down the artificial constructs built between communities that stem the tide of progress and create greater inequality. And we will address the future of AI and algorithms, intensify our work on frictionless data, and create fruitful, exciting partnerships with a growing list of global organisations. We will achieve all of this as the world struggles to recover from the coronavirus pandemic, and faces a new global recession and an ongoing climate emergency. There is a crossroad ahead, with a choice between two paths – open or closed. We must be the inspiration for others to follow and ensure society takes the most equitable route. It is an exciting time for our organisation. As we say a warm goodbye to our current CEO Catherine Stihler, we are all reflecting on what we have achieved and where we can go next. Catherine moves on to pursue an open world in her new role as CEO of Creative Commons in August, while OKF seeks an inspirational individual to lead us on our ongoing journey. The process of recruiting a new CEO will commence over the next few weeks. An open future has never been more important – will you join us to create it?

Comments Off on WANTED: Open Knowledge Foundation seeks visionary leader to steer the world towards a free, fair, and open society

Unveiling the new okfn.org website, blog and logo

Catherine Stihler - February 11, 2020 in Open Knowledge Foundation, Our Work

Today the Open Knowledge Foundation is launching its revamped website, updated blog and new logo. Our vision is for a future that is fair, free and open. This will be our guiding principle in everything we do. Our mission is to create a more open world – a world where all non-personal information is open, free for everyone to use, build on and share; and creators and innovators are fairly recognised and rewarded. We understand that phrases like ‘open data’ and ‘open knowledge’ are not widely understood. It is our job to change that. Our strategy, continuum and animated video aim for us to reach a wider and more mainstream audience with relatable and practical interventions. This renewed mission has limitless possibilities and the Board and team are excited about our organisation’s next steps and hopeful for the future. Please let us know any thoughts you have about our website, blog, animated video or new logo by emailing info@okfn.org.

Comments Off on Unveiling the new okfn.org website, blog and logo

OKI Agile: Kanban – the dashboard of doing

Tryggvi Björgvinsson - August 3, 2017 in agile, kanban, Our Work

This is the fourth in a series of blogs on how we are using the Agile methodology at Open Knowledge International. Originating from software development, the Agile manifesto describes a set of principles that prioritise agility in work processes: for example through continuous development, self-organised teams with frequent interactions and quick responses to change (http://agilemanifesto.org). In this blogging series we explore the different ways Agile can be used to work better in teams and to create more efficiency in how to deliver projects. Previous posts dealt with user stories, methodologies and the use of scrum and sprints in open data: this time we go into Kanban. Picking a methodology has to take into account both the team doing the work but also the project. Bigger teams call for a bigger methodology, and more critical projects call for more methodology density (higher ceremony or publicly visible correctness). Bigger methodology adds larger amount of cost to the project. So picking a big methodology, with high ceremony, for a small team and less critical projects is a waste of time, money and effort. Scrum is an example of a relatively big methodology with high ceremony (in the agile universe). There are daily standups, sprint backlogs and commitments, product owner, scrum masters etc. Always going for Scrum may make us look like we’re organised, but we might be organised in the wrong way.

Less can lead to more

The opposite of Scrum in the agile world is perhaps Kanban. It’s designed to not interfere in any way with how the team already works. It may even be an addition to Scrum. It’s a form of what has been called Just-In-Time delivery/development.

In Scrum the team creates a sprint backlog of what the team commits to and what will be worked on during the sprint. During the sprint, which typically ranges from 2-4 weeks, nobody can touch the backlog: nothing can be added, nothing can be modified. Items in the sprint backlog can only be closed. This is done to allow the team to focus on delivery, not requirements discussions. Kanban works on a different level. In Japanese Kan stands for card and ban means for signal. Kanban could therefore be translated as Card signals and that comes pretty close because Kanban is about using cards or some equivalent of cards to signal progress. It’s a card dashboard showing what’s being done where. There is no sprint that denotes work units, it’s just continuous work and planning when needed, or just in time.

Spreadsheet planning

In its essence, Kanban is progress visualised in a structured spreadsheet. You have columns that show different stages of progress or work. The different stages can include:

Incoming work
Brainstorming/Specifications
Implementation/development
Ready for review
In tests/proofreading
Ready for deployment
Deployed

This is not a be all, end all list. This is an example of what columns might be included. Kanban doesn’t tell us what columns we should use. Kanban is designed to be an addition on top of our current processes. The rows in our spreadsheet is used to track different aspects of the project. For example, if we have different members of the team working in different areas: Designers, content writers, software developers, a row would represent each area. This could also be used to track features of the project if the team is homogeneous (all team members work together in the same area, e.g. all software developers). The cells of the spreadsheet will then include requirements, for example user stories, that are in each stage for each feature or team. If we remember the requirements iceberg, this this is the 1-2 day tasks that we perform.

Visualising progress

As work progresses on each requirement item, it moves between the different columns. This creates the Kanban dashboard, visualising progress of the project. Kanban encourages autonomy and leadership on all levels. Every team member can come in each day, have a look at what’s needed and just do some work and then once done, move it between columns. That’s part of the just-in-time attitude. We don’t need to plan everything in beforehand, things will be done just in time. That means for managers, who normally push schedules for work to team members, they now have to sit back and give the team autonomy over the process. Likewise, team members who are used to being told what to do, now have to take matters into their own hands and pull the work that needs to be done.

What about prioritisation you may ask? What about team members just picking low-hanging fruit or easy tasks and leave all the boring tasks until last even if they are the highest priority? Kanban puts limits on each column. How many is up to the team, but it is not allowed to have more than a prefixed amount of requirements in each column at any given moment. So there might never be more than 8 incoming work items, 2 items being drafted, 3 being implemented etc. The only exception to this can be the last column, delivered which collects everything that has been done, but is usually not a part of the Kanban dashboard or if it is, then it’s regularly purged. So if the team wants to implement a drafted feature but the amount of items in the implementation column has already reached the maximum they need to sort that out first, before they can take on more implementation work. The project manager or client representative will typically manage the incoming work column but that one is also limited by the maximum amount and progress. Common sense should of course be applied to these limitations. If the team is heterogeneous, i.e. each row in the “pretend spreadsheet” is a different area instead of a different feature, the limitations apply to each of the cells in the column (e.g. we can’t have the content team limit the software developers just because they have more to do).

Principles

Kanban is really simple, it’s all about visualising the work flow and not overwhelming the team. It’s built around four principles:

It should work with whatever process is currently used by the team
It helps the team make small incremental changes towards improvement
It respects roles and responsibilities of each team member
To each her/his own, team members are autonomous and leaders over their own work

It should be really simple to pick up Kanban and add it on top of whatever you’re doing today. Kanban works really well for whiteboards but the biggest obstacle for a remote organisation is finding a good digital tool for the workflow visualisation; Trello might work if if you don’t care too much about the rows. Google spreadsheet might work if you don’t care about the extra effort of moving things around. If you find a good way to manage a Kanban board, please share it through the comments below or on our forum!

Comments Off on OKI Agile: Kanban – the dashboard of doing

OKI Agile: Scrum and sprints in open data

Mor Rubinstein - June 22, 2017 in agile, Our Work, scrum

This is the third in a series of blogs on how we are using the Agile methodology at Open Knowledge International. Originating from software development, the Agile manifesto describes a set of principles that prioritise agility in work processes: for example through continuous development, self-organised teams with frequent interactions and quick responses to change (http://agilemanifesto.org). In this blogging series we go into the different ways Agile can be used to work better in teams and to create more efficiency in how to deliver projects. The first posts dealt with user stories and methodologies: this time we go into using scrum and sprints to manage delivery of projects. Throughout my time as a project manager of open data projects in The Public Knowledge Workshop in Israel and in Open Knowledge International, I have used various tools and methods to manage delivery of software and content development. I have used Trello, Asana and even a Google spreadsheet, but at the end of the day I am always going back to Github to run all of the project tasks, assisted by Waffle. Many people that I spoke to are afraid of using GitHub for project management. To be fair, I am still afraid of Git, but GitHub is a different concept: It is not a code language, it is a repo site, and it has got really good functions and a very friendly user interface to use for it. So do not fear the Octocat!

Why Github?

As an open source community facing products, our code is always managed on Github. Adding another platform to deal with non-code tasks just adding more complications and syncing.
It is open to the community to contribute and see the progress and does not need permissions management (like Trello).
Unlike what people think – it is really easy to learn how to use Github web version, and it’s labels and milestones feature are helpful for delivery.

Why Waffle?

It syncs with Github and allows to show the tasks as Kanban.
It allows to write estimates that hours of work for each task.

So far, working on Github for the project showed the following:

Better cooperation between different streams of work
Having one platform helps the team to understand what each function in the project is doing. I believe that the coder should understand the content strategy and the community lead should understand the technical constraints while working on a project It gives back better feedback and ideas for improving the product.
Better documentation
Having all in one place allows to create better documentation for the future.

So what did we do for GODI (the Global Open Data index) 2016?

Firstly, I have gathered all the tasks from the Trello and moved it to the Github.
I created tags that allow to differentiate between different types of tasks – content, design, code and community.
I added milestones and sorted out all tasks to fit their respective milestones of the project. I also created a “backlog” for all tasks that are not prioritise for the project but need to be done one day in the future. Each milestone got a deadline that responds to the project general deadlines.
I made sure that all the team members are part of the repository.
I organised Waffle to create columns – we use the default Waffle ones: Backlog, Ready, In Progress and Done.

Using one system and changing the work culture means that I needed to be strict on how the team communicates. It is sometimes unpleasant and needed me to be the “bad cop” but it is a crucial part of the process of enforcing a new way of working. It means repetitive reminders to document issues on the issue tracker, ignoring issues that are not on GitHub and commenting on the Github when issues are not well documented. Now, after all is in one system, we can move to the daily management of tasks.

Sprints

Before the sprint call
- Make sure all issues are clear – Before each sprint, the scrum master (in this case, also the project manager), make sure that all issues are clear and not vague. The SM will also add tasks that they think are needed to this sprint.
- Organise issues – In this stage, prior to the sprint call, use the Waffle to move tasks to represent where you as a project manager think they are currently.
During the sprint call:
- Explain to the team the main details about the sprint:
  - Length of the milestone or how many weeks this milestone will take
  - Length of the sprint
  - Team members – who are they? Are they working part time or not?
  - Objectives for the sprint these derive from the milestone
  - Potential risks and mitigation

- Go through the issues: yes, you did it before, but going through the issues with the team helps you as PM or SM to understand where the team is, what blocks them and creates a true representation of the tasks for the delivery team.
- Give time estimates – Waffle allows to give rough time estimates between 1-100 hours. Use it to forecast work for the project.
- Create new tasks – speaking together gets the creative juices going. This will lead to creation of new issues. This is a good thing. Make sure they are labeled correctly.
- Make sure that everyone understand their tasks: In the last 10 minutes of the sprint, repeat the division of work and who is doing what.

After the sprint call and during the sprint:
- Make sure to have regular stand ups – I have 30 minute stand ups, to allow the team to have more time to share issues. However, make sure not to have more than 30 minutes. If an issue demands more time to discuss, this means it needs its own dedicated call to untangle it, so set a call with the relevant team members for that issue.
- Create issues as they arise – Don’t wait for the stand up or sprint kick-off call to create issues. Encourage the team and the community to create issues as well.
- Always have a look at the issue tracker – Making sure all issues are there is a key action in agile work. I start everyday with checking the issues to make sure that I don’t miss critical work.
- Hyper communicate – Since we are a remote team, it is best to repeat a message than not say it at all. I use Slack to make sure that the team knows that a new issue arise or if there is an outside blocker. I will repeat it on the team stand ups to make sure all team members are up-to-date.

Comments Off on OKI Agile: Scrum and sprints in open data

OKI Agile: Picking/Designing a Methodology

Tryggvi Björgvinsson - May 22, 2017 in agile, Our Work

This is the seond in a series of blogs on how we are using the Agile methodology at Open Knowledge International. Originating from software development, the Agile manifesto describes a set of principles that prioritise agility in work processes: for example through continuous development, self-organised teams with frequent interactions and quick responses to change (http://agilemanifesto.org). In this blogging series we go into the different ways Agile can be used to work better in teams and to create more efficiency in how to deliver projects. The first post dealt with user stories: this time we go into methodologies. More efficiency in project delivery is the name of the game. Working together in teams or with other people requires us to put in places methods and methodologies to accomplish that. A shared set of methods that allows team members to walk into a project and start delivering as soon as possible.

Glossary

Method – A systematic procedure.
Methodology – A series of related methods or techniques.
Methodology size – Number of methods/techniques used in the methodology.
Methodology density – Amount of precision/checkpoints needed. More density is a higher ceremony methodology (more formal one)
Criticality – The nature of damage of undetected defects (impact if we forget something). Higher criticality means worse impact.

What is a methodology

A methodology consists of 10 elements, of which one, the team values, permeates all of them. Let’s first put them in a pretty picture and then list them out with descriptions:

Team values – What the team strives for, how they’d like to communicate and work together. The values affect each element of the methodology so different values create different methodologies.
Roles – It’s best to think of this as the job descriptions we’d put into the ads when you need to hire more staff.
Skills – The skills needed for the roles we need.
Team – This is the group of people that will tackle a project and what roles they have.
Tools – The tools people use either within a technique/method or to produce a deliverable according to the standard.
Techniques – The methods used to get stuff done (generate work product), this can be everything from work changing techniques like breaking up into sprints (time blocks for work), to games played to achieve a specific output like planning poker (for estimates), to just a description of what is done to make things happen like “write a blog post”.
Activities – The meetings, reviews, milestones and other things people do or attend. The most obvious activity is “create deliverable” or something like that, but the more interesting activities are the events that take place.
Standards – Description of what is permitted and not permitted in the work product. These can be standards such as what programming language or security measures to use, how management is handled or how decisions get made (e.g. RASCI) and other project conventions.
Work Products – Not only the final product, this is also the internal products, i.e. what each person or team hands over to another person or team, something like user stories or mockups.
Quality – Often not considered explicitly but these are the rules and concerns that need to be tracked for each deliverable (work product). This could be a part of activities but it’s so important that it’s better to split it out.

Principles for picking/designing methodologies

There is no one size fits all methodology. There are methods one reuses between them (the shared set of methods/techniques people know about) and probably a default set one uses in absence of something more fitting. However, in general one needs to think about and pick/design methodologies based on two things:

The project itself
The number of people on the project team

The nature of the project calls for different methodologies, some projects can get away with a very lightweight methodology, where it won’t be the end of the world if something is forgotten, while others call for more publicly visible correctness where bad things happen if things are forgotten. For example, paying salaries requires a methodology with more visible checkpoints and correctness than responding to Tweets. People might lose their houses if they don’t get paid, but nobody will be out on the street for missing a possibility to retweet. A lot changes based on the number of people involved. Communications become harder to do and the effectiveness of individuals decreases as a result the methodology must get bigger to tackle all of these:

Picking/designing a methodology has to be based on these four principles (they have to be kept in mind so because they aren’t all achievable always, notably number 4 in our case):

Bigger teams call for a bigger methodology
More critical projects call for more methodology density (publicly visible correctness)
Cost comes with weight (a small increase in methodology adds large amount of cost of the project)
The most effective communication is face to face and interactive (everyone participates instead of just doing a broadcast).

Agile development

We have agreed on adopting the agile values (slightly adapted from the agile software values) as our team values where we can. That means we value:

Individuals and interactions over processes and tools
Working stuff over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

We value everything that’s mentioned above, we just value the things on the left (the bold) more than the things on the right. There are also 12 principles we try to follow as much as we can:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable things.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working stuff frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and implementers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a team is face-to-face conversation.
Working stuff is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

As an encouragement and because you were just bombarded with a long list of things and a discussion about planning how we plan work, here’s something from XKCD to keep in mind as we dive into methodologies:

Comments Off on OKI Agile: Picking/Designing a Methodology

OKI Agile: How to create and manage user stories

Tryggvi Björgvinsson - April 26, 2017 in agile, Our Work

This is the first in a series of blogs on how we are using the Agile methodology at Open Knowledge International. Originating from software development, the Agile manifesto describes a set of principles that prioritise agility in work processes: for example through continuous development, self-organised teams with frequent interactions and quick responses to change (http://agilemanifesto.org). In this blogging series we go into the different ways Agile can be used to work better in teams and to create more efficiency in how to deliver projects. The first blog is dedicated to user stories, a popular agile technique. User stories are a pretty nifty way of gathering requirements in an agile environment, where one of the key values is responding to change over following a plan. They are a good anchor for conversation that can then take place at the right time.

What is a user story?

A user story is a short sentence that encapsulates three things:

Who?
What?
Why?

Notice that this does not include “How?” The “How?” is left to the team delivering the requirement. After all, the team consists of the professionals. They know how to deliver the best solution. The most common way to encapsulate a user story is to use the template:

As a [WHO] I want [WHAT] so that [WHY]

Be careful not to sneak in any Hows into that template. That usually happens in the What so stay focussed! Words like by, using or with should be avoided like the plague because they usually result in a How. Basically avoid anything that has to do with the actual implementation.

Bad user stories

As a government official I want a Range Rover so that I can get from A to B quickly

Problem: A Range Rover is an actual implementation, it might not be what is needed even though it is what’s believed to be desired.

As a visitor to a website I want to be able to read a landing page using my spiffy MacBook Air and have the content presented in the Lato typeface, size 14, and with good white space between paragraphs so that I can know what the website is all about

Problem: A whole lot! What about GNU/Linux and Windows users? What if there is a better typeface out there? What about language of the content? The Why isn’t really a why. The list goes on. Don’t go into detail. It’s bad practice and creates more problems than it solves.

Good user stories

As a government official I want means of transportation so that I can get from A to B quickly
As a website visitor I want to know what the website is about so that I can see how it can help me

Why shouldn’t we go into details?

It’s really quite simple. We expect the requirements to change and we’d just waste a lot of time going into the details of something that might change or get thrown out. We’re trying to be efficient while still giving the team an understanding of the broader picture. An extreme example would be that between project start and time when the team is going to tackle a user story the world might have moved to virtual governments that don’t need transportation any more (technology moves fast).

The team also consists of experts so they know what works best (if not, why are they tasked to deliver?). The customers are the domain experts so they know best what is needed. In the website visitor example above, the team would know the best way of showing what a website is about (could be a landing page) but the customer knows what the customer is going to offer through the website and how they help people. We also value interactions and individuals over processes and tools. In an ever changing requirements environment we want non-details which can when the time comes be the basis for a conversation about the actual implementation. The team familiarises itself with the requirement at the appropriate time. So when starting work on the transportation user story, the team might discuss with the customer and ask questions like:

“How fast is quickly?”,
“Are A and B in the same city, country, on Earth?”,
“Are there any policies we need to be aware of?” etc.

Acceptance of user stories

Surely the customer would still want to be able to have a say in how things get implemented. That’s where acceptance criteria comes in. The customer would create a checklist for each user story when the time comes in a joint meeting, based on discussion. That’s the key thing. It comes out of a discussion. This criteria tells the team in a bit more detail what they need to fulfill to deliver the requirement (user story). For the government in need of transport this might be things like:

Main area of interest/focus is London area
Applicable to/usable in other cities as well
Allows preparations for a meeting while in transit
Very predictable so travel time can be planned in detail
Doesn’t create a distance between me and the people I serve

Then the implementation team might even pick public transportation to solve this requirement. A Range Rover wasn’t really needed in the end (albeit this would probably go against the “satisfy the customer” principle but hey! I’m teaching you about user stories here! Stay focussed!).

How is this managed?

One key thing we want to get out of user stories is to not scope the requirement in detail until it becomes clear that it’s definitely going to be implemented. How then do you know what you’ll be doing in the future? User stories can be of different sizes; From very coarse to detailed stories. The very coarse ones don’t even need to be written as user stories. They’re often referred to as epics. Many break requirements into three stages. The releases or the projects or whatever the team works on. Then each of these can be broken up into features and each feature can be broken up into tasks. It’s up to the team to decide when it’s best to formulate these as user stories and it really depends on the team and the project. Some might have epics as the big long term project, break that up into user stories, and then break each user story up into tasks. Others might have a single product, with the releases (what you want to achieve in each release: “The geospatial release”) at the top and then have features as sentences (epics) underneath the release and then transform the sentences into user stories you work on. Whatever way you do, this is the general guideline of granularity:

Coarsest: Long-term plans of what you’ll be doing
Mid-range: Delivery in a given time period (e.g. before deadlines)
Finest: What team will deliver in a day or two

The reason the finest level is in a day or two is to give the team a sense of progress and avoid getting stuck at: “I’m still doing the guildhall thing” which is very demoralizing and inefficient (and not really helpful for others who might be able to help). There is a notion of the requirements iceberg or pyramid which tries to visualise the three stages. The bottom stage is larger and bigger items (the coarse stuff), mid range is what you’re delivering in a time period, and the finest is the smallest blocks of work. That’s what’s going to be “above” surface for the core team. That’s still just a fraction of the big picture.

When should who be involved?

So the core team has to decide at what stage of the iceberg they want to write the user stories, and that kind of depends on the project, the customer, and the customer’s involvement. So we need to better understand “the team”. The core team should always be present and work together. Who is in the core team then? If that’s not clear, there’s a story/joke, about the pig and the chicken, that can guide us: A pig and a chicken decided to open up a restaurant. They were discussing what name to give the restaurant when the chicken proposed the name: Ham & Eggs. The pig sneered its nose and said: “That’s unfair, I’d be committed but you’d only be involved!”

That’s the critical distinction between the core team and others. The core team is the pigs. Everyone else who is only involved to make the project happen is a chicken. The pigs run the show. The chickens are there to make sure the pigs can deliver. Chickens come in various sizes and shapes. It can be team managers (planning persons), unit heads, project managers, biz-dev people, and even customers. The term customer is pretty vague. You usually don’t have all your customers involved. Usually you only have a single representative. For bespoke/custom development (work done at the request of someone else), that person is usually the contact person for the client you’re working for. At other times the single customer representative is an internal person. That internal individual is sometimes referred to as the product owner (comes from Scrum) and is a dedicated role put in place when there is no single customer, e.g. the product is being developed in-house. That person then represents all customers and has in-depth knowledge about all customers or has access to a focus group or something. This individual representative is the contact point for the team. The one who’s there for the team to help them deliver the right thing. More specifically this individual:

Creates initial user stories (and drives creation of other user stories)
Helps the team prioritise requirements (user stories)
Accepts stories (or rejects) when the team delivers
Is available to answer any questions the team might have

So the representative’s role is to provide the implementers with enough domain knowledge to proceed and deliver the right thing. This individual should not have any say in how the core team will implement it. That’s why the team was hired/tasked with delivering it, because they know how to do it. That’s also why user stories do not focus on the how. The core team, the pigs, need to decide at what intersections in the iceberg they want to have this representative present (where discussions between the core team and the representative will happen). When they go from coarsest to mid-range or from mid-range to finest. So in a weird sense, the core team decides when the customer representative decides what will be done. As a rule of thumb: the user stories feed into the stage above the intersection where representative is present. So if the representative helps the team go from coarse to mid-range, the user stories are created for the mid-range stage. If the representative is there for mid-range to finest, the user stories are going to be very fine-grained. As a side note, because the chickens are there to make sure the pigs can deliver, they will always have to be available to answer questions. Many have picked up the standup activity from the Scrum process to discuss blockers, and in those cases it’s important that everyone involved, both pigs and chickens, is there so the chickens can act quickly to unblock the pigs.

Now go and have fun with user stories. They shouldn’t be a burden. They should make your life easier… or at least help you talk to chickens.

Comments Off on OKI Agile: How to create and manage user stories

OKI website upgrade – what we have done and the road ahead

Mor Rubinstein - August 4, 2016 in Our Work, team, website

An organisation website is its main public image or at least this is what we believe in at Open Knowledge International. For a while now, our website has needed design attention and update of content. We have therefore decided to revamp our website and give it some new look and features.

Our primary thinking behind our site is how to make the work and the people of Open Knowledge International more relatable. How can we take complex terms like open data and civic tech and make them something that anyone can relate to? Also, we wanted to see how the OKI team can use the website to connect and learn more about one another. Also, we wanted the site to reflect our how we are working towards our mission, to make “A world where knowledge create power to the many, not the few.” We highlighted our projects and how they strive towards that goal.

Our work on the site is not done, and probably will always be a work in progress. We believe in “release fast, release often” approach, and hope that you can give us feedback about the website, as well as help us to find bugs (although we tried to catch them all in advance!). Like all of our work, you can get the source code for the website here, and use it for your work if you see something that you like.

So what did we do?

A new homepage – We believe that people are in the focus of our work and we tried to reflect it on our homepage. Here you can see highlights of our work, latest projects and navigate to sections that explain to you who we are and what we are doing.
Project page – For the last two years, the OKI website didn’t have a project page. Since our projects are the core of our work, we added a project page where you can see all of our past project and all the projects that we are currently working on.
Network Guidelines – We move our network guidelines from a google doc to the website so it will be easier to find them.
New page templates – We gave our general pages a new look and improved the navigation on the site.
A new team page – We are very proud of our diverse and global team, but we wanted to make our team page a bit more than that. As a remote team, our office is our “Slack” channel (yes, yes, we don’t have a physical office!). Working in the virtual space has a lot of advantages, but it is very hard to get to know your teammates on a closer level. We, therefore, decided to use both our website and Slack to create a feature that will allow both the team and you, the users, to get to know team members better. OKI team members can update their team member page status by updating Slack in 5 categories – reading, eating, listening, working and location. This way you can know in real time where are we and what are we doing. It already provoked some excellent conversations in within our staff, and I hope it will make you closer to us as well.

An example for our new team page

What are we planning to do next?

Network page – we want to give the network page a new look so it will be easier to understand who is part of the OKI network and what different parts of the network are doing. The content there is up to date, and we will keep updating it.
Research – During the years we have done a lot of research in OKI. We want to give it a dedicated place on the site (in the meanwhile, you can find our work on our research repository).
Funding – We would like to improve our funding page and give you more information about or sources of financing. We are now examining what will be the best way to do so.
Press page – The current page has outdated content. Sierra Williams, our incoming Communication Manager, will update this page and will lead the future work on the whole website.

Let us know what you think about our site by leaving some feedback about it on our forum.

Comments Off on OKI website upgrade – what we have done and the road ahead

Open Access: Why do scholarly communication platforms matter and what is the true cost of gold OA?

Danny Lämmerhirt - July 15, 2016 in Featured, Open Access, Open Research, Open Science, openmaccess, Our Work, PASTEUR4OA, Policy

During the past 2,5 years Open Knowledge has been a partner in PASTEUR4OA, a project focused on aligning open access policies for European Union research. As part of the work, a series of advocacy resources was produced that can be used by stakeholders to promote the development and reinforcement of such open access policies. The final two briefing papers, written by Open Knowledge, have been published this week and deal with two pressing issues around open access today: the financial opacity of open access publishing and its potential harmful effects for the research community, and the expansion of open and free scholarly communication platforms in the academic world – explaining the new dependencies that may arise from those platforms and why this matters for the open access movement.

Revealing the true cost of gold OA

“Reducing the costs of readership while increasing access to research outputs” has been a rallying cry for open access publishing, or Gold OA. Yet, the Gold OA market is largely opaque and makes it hard for us to evaluate how the costs of readership actually develop. Data on both the costs of subscriptions (for hybrid OA journals) and of APCs are hard to gather. If they can be obtained, they only offer partial but very different insights into the market. This is a problem for efficient open access publishing. Funders, institutions, and individual researchers are therefore increasingly concerned that a transition to Gold OA could leave research community open for exploitative financial practices and prevent effective market coordination. Which factors contribute to the current opacity in the market? Which approaches are taken to foster financial transparency of Gold OA? And what are recommendations to funders, institutions, researchers and publishers to increase transparency? The paper Revealing the true costs of Gold OA – Towards a public data infrastructure of scholarly publishing costs, written by researchers of Open Knowledge International, King’s College London and the University of London, presents the current state of financial opacity in scholarly journal publishing. It describes what information is needed in order to obtain a bigger, more systemic picture of financial flows, and to understand how much money is going into the system, where this money comes from, and how these financial flows might be adjusted to support alternative kinds of publishing models.

Why do scholarly communication platforms matter for open access?

Over the past two decades, open access advocates have made significant gains in securing public access to infrastructures

the formal outputs of scholarly communication (e.g. peer reviewed journal articles). The same period has seen the rise of platforms from commercial publishers and technology companies that enable users to interact and share their work, as well as providing analytics and services around scholarly communication.

How should researchers and policymakers respond to the rise of these platforms? Do commercial platforms necessarily work the interests of the scholarly community? How and to what extent do these proprietary platforms pose a threat to open scholarly communication? What might public alternatives look like?

The paper Infrastructures for Open Scholarly Communication provides a brief overview of the rise of scholarly platforms – describing some of their main characteristics as well as debates and controversies surrounding them. It argues that in order to prevent new forms of enclosure, it is essential that public policymakers should be concerned with the provision of public infrastructures for scholarly communication as well as public access to the outputs of research. It concludes with a review of some of the core elements of such infrastructures, as well as recommendations for further work in this area.

Comments Off on Open Access: Why do scholarly communication platforms matter and what is the true cost of gold OA?

New Initiative: Open Data for Tax Justice #OD4TJ

Jonathan Gray - March 2, 2016 in Campaigning, Featured, OD4TJ, Open Data, Open Government Data, Open Knowledge, Our Work, Public Money

Every year countries lose billions of dollars to tax avoidance, tax evasion and more generally to illicit financial flows. According to a recent IMF estimate around $700 billion of tax revenues is lost each year due to profit-shifting. In developing countries the loss is estimated to be around $200 billion, which as a share of GDP represents nearly three times the loss suffered by OECD countries. Meanwhile, economist Gabriel Zucman estimates that certain components of undeclared offshore wealth total above $7 trillion, implying tax losses of $200 billion annually; Jim Henry’s work for TJN suggests the full total of offshore assets may range between $21 trillion and $32 trillion. We want to transform the way that data is used for advocacy, journalism and public policy to address this urgent challenge by creating of a global network of civil society groups, investigative reporters, data journalists, civic hackers, researchers, public servants and others. Today, Open Knowledge and the Tax Justice Network are delighted to announce the launch of a new initiative in this area: Open Data for Tax Justice. We want to initiate a global network of people and organisations working to create, use and share data to improve advocacy and journalism around tax justice. The website is: http://datafortaxjustice.net/ and using the hashtag #od4tj. The network will work to rally campaigners, civil society groups, investigative reporters, data journalists, civic hackers, researchers, public servants and others; it will aim to catalyse collaborations and forge lasting alliances between the tax justice movement and the open data movement. We have received a huge level of support and encouragement from preliminary discussions with our initial members, and look forward to expanding the network and its activities over the coming months. What is on the cards? We’re working on a white paper on what a global data infrastructure for tax justice might look like. We also want to generate more practical guidance materials for data projects – as well as to build momentum with online and offline events. We will kick off with some preliminary activities at this year’s global Open Data Day on Saturday 5th March. Tax justice will be one of the main themes of the London Open Data Day, and if you’d like to have a go at doing something tax related at an event that you’re going to, you can join the discussion here.

Comments Off on New Initiative: Open Data for Tax Justice #OD4TJ

A Data Revolution that Works for All of Us

Rufus Pollock - September 24, 2014 in Featured, Open Data, Open Development, Open Government Data, Our Work, Policy

Many of today’s global challenges are not new. Economic inequality, the unfettered power of corporations and markets, the need to cooperate to address global problems and the unsatisfactory levels of accountability in democratic governance – these were as much problems a century ago as they remain today. What has changed, however – and most markedly – is the role that new forms of information and information technology could potentially play in responding to these challenges.

What’s going on?

The incredible advances in digital technology mean we have an unprecedented ability to create, share and access information. Furthermore, these technologies are increasingly not just the preserve of the rich, but are available to everyone – including the world’s poorest. As a result, we are living in a (veritable) data revolution – never before has so much data – public and personal – been collected, analysed and shared. However, the benefits of this revolution are far from being shared equally. On the one hand, some governments and corporations are already using this data to greatly increase their ability to understand – and shape – the world around them. Others, however, including much of civil society, lack the necessary access and capabilities to truly take advantage of this opportunity. Faced with this information inequality, what can we do? How can we enable people to hold governments and corporations to account for the decisions they make, the money they spend and the contracts they sign? How can we unleash the potential for this information to be used for good – from accelerating research to tackling climate change? And, finally, how can we make sure that personal data collected by governments and corporations is used to empower rather than exploit us?

So how should we respond?

Fundamentally, we need to make sure that the data revolution works for all of us. We believe that key to achieving this is to put “open” at the heart of the digital age. We need an open data revolution. We must ensure that essential public-interest data is open, freely available to everyone. Conversely, we must ensure that data about me – whether collected by governments, corporations or others – is controlled by and accessible to me. And finally, we have to empower individuals and communities – especially the most disadvantaged – with the capabilities to turn data into the knowledge and insight that can drive the change they seek. In this rapidly changing information age – where the rules of the game are still up for grabs – we must be active, seizing the opportunities we have, if we are to ensure that the knowledge society we create is an open knowledge society, benefiting the many not the few, built on principles of collaboration not control, sharing not monopoly, and empowerment not exploitation.

Comments Off on A Data Revolution that Works for All of Us