justicehub-in / justicehub

An open source platform for data related to the Indian legal and justice system. Crowdsourced from a community of law and data researchers, practitioners and enthusiasts.
https://justicehub.in
GNU Affero General Public License v3.0
2 stars 0 forks source link

JH - Standardizing Documentation #1

Open shashank-sharma opened 3 years ago

shashank-sharma commented 3 years ago

README Documentation that needed:

Repository level changes:

Extra work:

apoorv74 commented 3 years ago

@shashank-sharma instead of using Rocket Chat for interactions, can we use the JH Forum? We can create a separate category for these converations such as JH-Tech or something similar and add content on how people can use that to discuss tech at JH, etc.

shashank-sharma commented 3 years ago

@apoorv74 That was my first impression, Initially I thought there was a possibility of RC but it's not possible, that's why I added discourse link in README.md (Can be visible as tag at top)

Now since Discourse is forum, anyone can create post over there right ? There are already categories defined so I don't think any changes is required as such

apoorv74 commented 3 years ago

@shashank-sharma let's include the tag so its more visible.

On Discourse:

shashank-sharma commented 3 years ago

@apoorv74 That works, I'll ask Abhinav to create one category (or if you can that would be great), then I'll update the link.

One thing what we should start doing is categorizing issues based on repository.

  1. If justicehub level (like business logic, flow, process, decision) -> this repo works
  2. If login is not working, auth etc -> then ckanext-emailauth
  3. If some frontend error -> ckanext-justicehub_theme

I don't know how annoying it might become, but it's much better. And having tech discussion / updates via issues / PR in justicehub github (helps in having history of tech discussion / contributors understanding the roadmap)

apoorv74 commented 3 years ago

@shashank-sharma i agree, we should do that. you can create this mapping as per your understanding and then we can review.

shashank-sharma commented 3 years ago

How I see, issues can be: Based on contributor:

  1. Internal
  2. External

Based on issue:

  1. Business logic (example: login process should change)
  2. Development
  3. Vulnerability / major bug

Hence, internal + Business logic = Taiga (should do research on making it open source if possible) internal + Development = Github + Project board external + Business logic = Forum external + Development = Github (internal/external) + Vulnerability / Major bug = Mail / RC

Tools we will use:

  1. Taiga - No issues there
  2. Github issues - Will start maintaining and creating tags
  3. Github Project board - Need research on this
  4. Forum - Need to create category for development
  5. Mailing - No issues, it should be active

Github categories:

  1. Justicehub - Ideally business logic (if we move from taiga to github)

Main goal should be making this repository for whole CKAN + JH setup infra anywhere as development + production. It's a team call should we focus on this or not

  1. ckanext-emailauth - Anything related to Authentication
  2. ckanext-moderation - Anything for Dataset
  3. ckanext-justicehub_theme - Theming

Plugins will always be a separate entity (except those which were made for project, like themes), it should never be related to any specific project hence issues should be specific to that only. It will be maintainers responsibility to make sure that right issues are raised.