Your profile picture

Make technical development more open for non-CSA-organisations

As a lot of the web-technical needs of CSAs are similar to other organisations working in sustainable sections I'd prefer to open our communication-process to non-CSA-organisations aswell.

Our goal could be to define our requirements as abstract/open as possible to have a target group as broad as possible. Example: instead of "we need a listing of our harvest-depots including contact persons" we could define "we need the possibility to list data records (= harvest-depots) with variable informations to show and it shall also be possible to show data from other related data records (=contact person, possibly member of local CSA)".

By this our solution would be usable by many more organisations + we might get more developers involved.

We collected some contacts when we thought about developing the website http://transition-initiativen.de/ (Site of the transition network). I've created a page with these contacts (deleted personal email-addresses before), so feel free to add your contacts there.

What do you think about opening the dev-plans to the broader community?

Cheers,

Michael

  • 763 reads

Comments

Your profile picture

From agile software development perspective, I would disagree. It would be better to describe concrete requirements for our german CSA. But the implementation should be done in a way that it is flexible and easy to extend. But that's how drupal works, I guess ;o)

Your profile picture

I agree with Michael and that was actually the model that was thought for the development of co-munity - find commons needs, develop together. In my opinion, I don't see this being incompatible with an agile development perspective - and yes, Drupal is an agile CMS ;)

I agree also with Marc that we need to describe concrete requirements for the German CSA. However, the implementation can - and in my opinion should - be articulated with needs from other groups/initiatives. On the boat are the whole R&D and post-Degrowth conference stuff; tools for the Transition Network and initiatives (Germany, but maybe also UK, since they seem to also have chosen OA2); food cooperatives; trainers networks (GROWL).

The procedure in this case could be something like:

  1. look at specific needs separately
  2. plan together (e.g. scrum planning meeting)
  3. develop together (e.g. a scrum sprint)
  4. test separately
  5. fork when needed (fine tuning for separate uses)

I think by following such a model, we address what is usually the bottleneck of development for grassroots initiatives - human and monetary resources - by bringing together the little bits of each. In this sense, the list of contacts of Michael is a great first step (you might also want to read a few discussions I had 2-3 years ago and which resulted in this post and group before landing on ice). Please note that also the German Transition Netzwerk is *probably* getting involved in the development of co-munity and Hannes has actually been already active here.

As for workflow and tools: we started a GitHub project some time ago, but didn't really use it yet. I think it can be a good strategy to get everything related with makefiles, module and theme development there. I'm not sure about UI changes though, but I assume these can be exported as features and also added to the GitHub repository for reuse.

What do you think?

Your profile picture

Following the suggestion to make development more open to others - but also because I also wanted for sometime to create a kind of public invitation and structure the development process - I have posted this issue on the co-munity space.

I suggest that we further discuss how to collaborate on this open development there, while keeping whatever is CSA-specific (or whatever you find relevant to) here.