search

OpenDataforWeb3 / Resources

Resources including the Landscape, FAQs, and other information
44 stars 18 forks source link

Creating and restructuring labels #139

Closed poupou-web3 closed 1 year ago

poupou-web3 commented 1 year ago

To improve collaboration within ODC, issues can have labels that will better define the scope of the issue. It will also help working group to review their on going and done work during the weekly meettings.

poupou-web3 commented 1 year ago

Current labels are

I suggest to organise labels by group with the first word giving information about the purpose of the label. This is inspired by projects such as numpy So for example if we name the working groups pods we will have the following labels:

Under pods we may have components or modules

Adding the pod should be mandatory on each issue (may need to be added to contribution guideline), also in theory an issue should be addressed by only one working group but for now we should let anyone add two pods to an issue. For example, https://github.com/OpenDataforWeb3/Resources/issues/133 is overlapping with the outreach and hackathon pods and it may be assigned both labels.

I think default labels such as bug, enhancement.. are still needed especially for engineering pod and should be kept.

I do not propose to add tags such as priority: high because this can be managed on github project page. On the other hand I don't think it will be available in Dework or Linear wich may create dupplication of information.

This is already an exhaustive list but on the long run any one could add a label with relevant meaning to organize issues.

Please let me know what you think @sarob and anyone interesting.

G-r-ay commented 1 year ago

The pre-hackathon write up appears to be much more inclined with the hackathon team than it is with the publishing comms team, although I believe the flow of that task is more step based with the hackathon group getting at least a baseline done. I do see the need for structuring issues according to their pods, and the situation of an issue overlapping could be fixed by choosing which group has to more influence in the space of that issue.

Just may extra addition but I was also thinking in the sub-sub-sub tags (quite a lot of subs🥴) like the bug, duplicate, etc. we could also have a Correction tag whose base purpose will be to fix typos and errors that do not filtered out in a PR review

@poupou-web3 @sarob what do you think?

poupou-web3 commented 1 year ago

I was referencing the pre hackathon issue in both pods because it has that at the end

We need 2-3 sponsors, should get in touch immediately

Which is relevant to the outreach group, it could also be a separate issue with the label pod: outreach, comp: hackathon At the same time creating similar label is confusing.

I agree for te sub definition of bug labels, for example bug: typo, bug: hugo, bug: outdated @G-r-ay

sarob commented 1 year ago

If we change the prefix pod to group then I’m in favor of implementing the first group of labels right now. We can continue to call ourselves working groups. I think we need these now so we can filter issues in GitHub project views.

I’m a cautious about creating and using more than a few new labels before making more changes.

This is a great write up. Thank you for considering this so thoroughly!

G-r-ay commented 1 year ago

Considering this:

I’m a cautious about creating and using more than a few new labels before making more changes.

Let's start of with the pod division and as need arises for extra details in issues we could implement the other subdivisions

@sarob @poupou-web3 what do you think?

sarob commented 1 year ago

agreed with the change of pod to group. we are already calling ourselves working groups so I don't want to introduce new terms that may confuse people.