Issue per event vs Issue per hack?

[djay]

Current data model (A) is

• repo
  • issue = event
    • comment = hack = person (1 comment per person only)

Alternative (B) would be

• repo
  • issue (with tag or special text in title) = hack/person at event.

Alternative (C) seperate projects/hacks from RSVP at event

• repo
  • issue = event
    • comment = RSVP = person
    • links to projects - UI to suggest from existing projects
  • issue = project e.g. learn python
    • comment = participation in project

So same as A except no freeform text, only create and add links to projects

Problems trying to solve

• Social/Commenting

  • A: no way to comment on other peoples projects. have to do it manually my creating an seperate issue and linking to it
  • B: gives ability to discuss for one event
  • C: gives ability to discuss spanning over multiple events

• Notifications

  • A: everyone who creates a hack gets notified by email everytime some adds another hack/comment. Can you can unsubscribe to that issue if you want
  • B: I think by default you don't follow the repo as a whole. So won't get notifcation of other hacks
  • C: People would get notified twice, once for RSVP and another when they add a project. Might have auto unsubscribe people to event notifications?

• How easy/hard it is to roll over to new event.

  • A: have to create a new issue. could be automated if date rolls over? but hard to move comments from one issue to another if you forget
  • B: Can relabel to move hacks.
  • C: same as A but at least any long text on the projects enter before rollover is not lost

• Reusing a hack between events

  • A: if reusable hack is seperate from the event comment, then its easy to relink. Just got to make it nice UI to link issues to the hack. ie "link issue" button?
  • B: "link issue" button would have to add multiple labels/special text to the same issue

• Handling historical views on what people did previously

  • A: Can get good summary viewing one event ticket
  • B: Can use some search to find all projects
  • C: Can do both.

[djay]

@waf @pangaunn @ches I tried the sum up the pros and cons of if we switch to a different data model. There might be others.

[ches]

Yeah I was thinking this deserved a dedicated issue, there is some related discussion scattered in non-obvious places. See #10, #7 and #18.

[waf]

Thanks @djay and @ches. Just to clear up some terminology, when we say "label" or "re-label" it must mean updating some metadata either in the issue title or description, and not a "github label". This is because github labels require the user to be a member of the repo, which we want to avoid.

[djay]

@waf yes. All this hinges on if there is some way that you can use some special markup in the issue title for example to collect the issues together that doesn't require additional permissions. Or if github changes its permissions model.

[djay]

Talking with @waf I think the best of both worlds is single comment = RSVP and that can only consist of a series of links to projects. Projects are issues that can be live on outside of hacknights and be reused. When someone adds their hack they type an auto completion that searches for similar projects and the user can join existing or create their own. On the map you can have indicators to show new comments or who else has added that project to their RSVP for this hacknight. They click to open the project and discuss.

[djay]

@waf @ches if we do option C I'm guessing it would make it worse from rate limiting point of view. Since we need to do api calls for every linked project to show a map?

[djay]

@waf @ches I think this feature request boils down to a UI something like this.

1. Fred clicks "add new plan" <- (I think hack might be too obtuse?)
2. Fred has choice of either
   • reopen old project
   • join current project
   • create new project
   • free form plan
3. Fred wants to create a new project. Goes to git up create new ticket. Creates "lasers on sharks"
4. Sally adds a plan and selects "join current project"
5. Sally can search for suggested projects. (somehow get details while being able to come back and look at the next?)
6. Sally selects "lasers on sharks". Puts her on the list as "Joining 'Lasers on sharks'". Adds comment to laser card so she becomes a contributor. Her tag shows title and numbers of contributors and links to the ticket and has an extra button "join".
7. Jimmy browses the map, sees sally location and link to the project.
8. Jimmy clicks join bitton
9. Jimmy is now in the "join current project" dialog with the project name filled out.
10. End of the night admins close all the projects automatically.

What do you think?

[waf]

Thanks for putting that together. That user flow makes sense to me. First iteration could probably include only the "create new project" and "join a project" concepts. "Reopen old project" and "free-form plan" could be done later.

I think this also leads us in the direction of Alternative (B) in your original comment.