Decide on job attributes

[trickvi]

Decide on the attributes for job ads on the Jobs page

[nealbastek]

introduction
role description
required skills and experience
location
pay and benefits
how to apply

[nickstenning]

I presume this was closed accidentally.

[trickvi]

No, this is a ticket for @nealbastek and now that he has decided on the job attributes he can close the ticket. I'll move the decision into its own documentation, e.g. to the comments of the job page ticket. I'll also put it into the docs folder where I'll try to archive all decisions.

[nickstenning]

Sorry, but this isn't a complete list, hence my reopening it. The work I did yesterday on the jobs page was only a technology spike, not an attempt to solve the issue of the jobs page, but even in that context it was obvious that jobs need contact information and a submission end date, both of which are missing from this list.

[trickvi]

@nealbastek Do you have any comments on this?

[nickstenning]

Also, I'm not trying be a stick-in-the mud or foment an "issue war," so sorry if that's what it looked like. I'm just more of the "a story/issue/ticket is a placeholder for a conversation" school of thought -- data modelling in particular needs to be a conversation involving more than one person :)

[trickvi]

No no. This is all valid. My thought is basically this:

We create an issue for each task, we prioritise those at the beginning of each weekly sprint in the order we want them to be solved, when somebody solves it, it gets marked as closed (solved).

That does not mean that it is finalised and set in stone. We're smart people, if we notice something which isn't in the solution then we can just add it (e.g. in the implementation).

If there is any dispute or discussion needed then we can either reopen it or create a new issue (I would prefer the latter). I just want us to be working fast, closing tickets and not going back and forth while we're in sprints. Our sprints are relatively short so we can tackle any discussions at our Friday sprint planning sessions.

So focus more on getting things done than documentation or reaching consensus. Then we iterate.

We're working closer to the iterative development methodology than incremental development (which is why I prefer creating new issues instead of reopening). However the last thing I want to do is butt in on processes you @nickstenning and @nealbastek, feel comfortable following. We just have to all work similarly (the process should be as natural to you as possible to increase efficiency) and this is a suggestion for how to do that, feel free to make suggestions for better ways to do it (we can iterate on our development method as well as our software).

[nealbastek]

I'm really new to all this GitHub stuff and happy to be learning so I'm
going to follow your leads. I'd love some time at the summit to actually
sit down with any of you in front of a screen and actually look at things
together so I could have a better understanding.

And I definitely want to work out the data models collaboratively.
Something for Nick and I in Berlin when I'm there the week after?

Neal Bastek
Digital Engagement Director | skype: nealbastek |
@nbastekhttps://twitter.com/nbastek
The Open Knowledge Foundation http://okfn.org
Empowering through Open Knowledge
http://okfn.org/ | @okfn https://twitter.com/OKFN | OKF on
Facebookhttps://www.facebook.com/OKFNetwork |
Blog http://blog.okfn.org/ | Newsletterhttp://okfn.org/about/newsletter/

On Wed, Jan 8, 2014 at 7:46 AM, Tryggvi Björgvinsson <
notifications@github.com> wrote:

No no. This is all valid. My thought is basically this:

We create an issue for each task, we prioritise those at the beginning of
each weekly sprint in the order we want them to be solved, when somebody
solves it, it gets marked as closed (solved).

That does not mean that it is finalised and set in stone. We're smart
people, if we notice something which isn't in the solution then we can just
add it (e.g. in the implementation).

If there is any dispute or discussion needed then we can either reopen it
or create a new issue (I would prefer the latter). I just want us to be
working fast, closing tickets and not going back and forth while we're in
sprints. Our sprints are relatively short so we can tackle any discussions
at our Friday sprint planning sessions.

So focus more on getting things done than documentation or reaching
consensus. Then we iterate.

We're working closer to the iterative development methodology than
incremental development (which is why I prefer creating new issues instead
of reopening). However the last thing I want to do is butt in on processes
you @nickstenning https://github.com/nickstenning and @nealbastekhttps://github.com/nealbastek,
feel comfortable following. We just have to all work similarly (the process
should be as natural to you as possible to increase efficiency) and this is
a suggestion for how to do that, feel free to make suggestions for better
ways to do it (we can iterate on our development method as well as our
software).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-31828126
.

[nickstenning]

As and when we have clear requirements to change what's there, let's open a new ticket. Closing this one.