Generic issue pattern? (civic participation, city planing, ...)


#1

Hi, this is Matthias, I’m looking forward on forgefeed not only as software developer, but also as somebody that is interested in civic participation community. I work at the city of Rostock, where we maintain klarschiff-hro, a platform to spot on damaged city furnitures, wild waste, etc. and delegate it to the right partner of public services. We are also part of the open311 community, that is an open protocol for clients submitting issues.

But our experience is, that we lack of an federation-system, that allows us to share and collaborate on (more complex) issues. As said open311 is limited to the client side and doesn’t cover any aspect of internal workflows within / between organisations that work on the submitted issues. For that reason I like to ask, if forgefed ISSUES might become a bit more generic, not to tied to software repositories only?

From my (limited) point of view, there are a lot of common aspects of ticket systems in general:

  • accepting issues (fulfil content requirements, categories, …)
  • status updates (status, progress, …)
  • comments (internal, external, …)
  • refer other tickets and objects (duplicates, commits, …)
  • move tickets between instances - finding the responsible person (in software engineering: from distro package maintainer to upstream core development team, in real world: from one municipality to the neighbour municipality or upstream to a federal organisation)
  • notify involved instances on updates

I’m very happy on the work, that is already done by ActivityPub and for what I found out, your plans cover already a lot of this things. But more important is, if you see Forgefed in that generic way?


#2

Hallo Matthias,

I wish I could be more eloquent here, but my mind only says “yes”. :smiley:


#3

Regarding your final sentence, I would say that I think that in the end there might not be one single ForgeFed spec, rather 2 or 3 “independent” specs which the working group than combines to the one-and-only, ultimate ForgeFed spec to rule them all.

For example the ticket tracking (or as I call it: BITT, abbreviation for Bug/Issue/Ticket Tracking), might have it’s own small spec and ForgeFed might just reference it. Like ActivityPub references ActivityStreams. :slight_smile:


#4

another way to look at it is simply this: in a federated network, one can not expect that all or any specific aspects of the protocol will be fully implemented on any given instance - every admin is free to implement as much or as little of the spec as they need - if the spec has any parts that you can make use of, and those parts are implemented to spec, then that is sufficiently generic to be functional with any other instance that support those features