Add classification system for projects about librecores-web HOT 17 CLOSED

We probably should have categorized tags, by which I mean that tags are grouped (by color or ":"). Such categories are for example ISA, Language, etc.

from librecores-web.

I assigned this to myself as it is not on the highest priority and can help me learn the Synfony framework

from librecores-web.

This bug has been marked as a "good first bug". If you're interested in working on it, have a look at the developer documentation at http://librecores-web.readthedocs.io/en/latest/ and comment on this bug or contact the listed mentor for more details. The mentor will be available to help you complete this task.

Mentor: @imphil @wallento
Required Skills: PHP (Symfony), a bit of HTML, CSS

from librecores-web.

A potential good starting point is this:

• Slides: http://de.slideshare.net/fogs24/sfughh-ta
• Project: https://github.com/fogs/tagging-bundle

from librecores-web.

There is a first draft in the tags branch. I think from the entities we are ready. Missing:

• Frontend: @berndca, can I interest you in helping me with that?
• A management entity to add tags (possibly accessible by users in lets say librecores org)

from librecores-web.

@wallento Of course I'm willing to help. However I must admit that I feel lost. Perhaps it's because I missed the discussions you guy's had earlier. I have read the road map several times, but I have a hard time reconciling the statements in the road map with what I'm seeing. Again, perhaps I do not have all the information? This starts with why are we building what looks to be a github clone. Why not focus on building an app on top of github? The implementation choices Github made were to a large extend driven by their need to scale. Unfortunately the FOSSi community is rather small which renders many of the design choices Github made irrelevant for librecores. On the other hand this being contrasted by a backend architecture which will not scale well at all. Is securing the server not a priority?

What is the plan? What is the next milestone? Where are the model specs?

About the specific issue at hand:

• Who is creating the tags (admin or user defined) and where is the template for the form?
• Who is doing the design (draw a picture of how the form should look like)?
• How are you planning to use the tags? (menu, tag cloud...)

I can understand that some contributors might get tired of discussing questions which have been discussed before. I'd be happy to talk in a call or chat on IRC if thats more convenient for you.

from librecores-web.

We're trying to build a useful community hub for people involved in Open Source Silicon projects. The project listing is one part of LibreCores. The rationale here is that people don't put their designs on opencores anymore, since it lacks many features that is expected of a modern site. Instead, many designs end up on github and other places, but there is not really a good place to find an overview of relevant projects. The tags support is a feature that has been requested so that designers can find all cores that have a Wishbone interface, or all SPI cores, or all RISC-V cores, so that they can use that in their design.

Other than the project listing, LibreCores aim to be a lot more. We already have mailing lists and the blog aggregator for those interested in news and announcements. We are also working on providing a continuous integration platform that is better suited for Open Source Silicon than existing online resources such as Travis. We want to provide feedback mechanisms and quality metrics for the projects listed, to make it easier to find good designs. We want to state relationships between projects to spread the idea of modularity and package management more in the HDL community.

There are more things brewing as well, but to answer one of your questions, other than the project listing itself, we need a lot of infrastructure that we can't build on top of an existing platform such as github.

We are all available on #librecores at freenode. Please join us for some chatting there as well.

from librecores-web.

@olofk I'm afraid that there might have been a misunderstanding about what constitutes a GitHub app. A GitHub app is a web application (website) that is registered with GitHub and uses resources provided by GitHub such as OAuth2 "Sign in with GitHub" and/or the GitHub API. Strictly speaking librecores.org is already a GitHub app because of the social sign in. I did explore the GitHub API a while back and built a very crude website to play with the data. The llanguage, license, forks, stars and time of last update were extracted from the GitHub API.

Lets look at another aspect of the relationship between librecores.org and GitHub. A feature which is currently creating some headaches is the README and License files on the project page. Currently these files are copied and editable. IMO this is bad because you end up with files out of sync potentially containing outdated or even conflicting information. I would just link to the repo home page on GitHub and let the user read the originals.

About the tags: I do understand how the tags could be useful. However there are enough options to make it worthwhile to ensure that everybody is on the same page. Here are some ideas:

1. User defined Tags: The users have full freedom to create and attach any tag they like to their project. The web app tries to detect when different user create the same tag with different spelling and tries to nudge to user to avoid duplicates.
2. Categories: The web team comes up with a taxonomy of fixed categories.
   2.a. The web team assigns categories to projects.
   2.b. The user applies for categories and the web team approves or denies the request.
   2.c. The user picks a category he feels matches best.

My question is, what are we trying to build? Tags, Categories, both?

from librecores-web.

Hi guys,

can we please move the general discussion to the mailing list or to new tickets. Regarding GitHub we are a GitHub app and should make use of its API wherever possible (see project activity badges). Most of the "meta-stuff" we do is not part of GitHub as in GitHub everything happens inside a project. This stuff we don't touch, its more how projects relate and how people see them, none of which is in the scope of GitHub. And this is the same for tags.

@berndca, to your question: Tags are "Categories" in your definition. They are predefined and users can (later) suggest additions. For example a RISC-V core implementation could have the tags "core:riscv", "language:verilog", "interface:AXI" and maybe something like "state:mature".

So, now I am at the point where we have the basic relations (Each project has multiple tags, each tag has a category, the tag full name is built as <category>:<name> and categories distinct by colors). Displaying them as labels is straight forward, what I would like to start discussing now is how the user edits the projects' tags in the frontend. I have seen a few js implementations, but non of them seems suited out of the box.

In my opinion the editing should be done"responsive" in-place at where the tags are displayed, by clicking "Edit tags". I assume a stright forward way would then be to transform tags to become "removable" and adding an input field to enter new tags. Typeahead will show allowed tags, non allowed should be rejected.

Please comment if this is generally a proper direction or if you think another approach to project tags editing is better (via the settings, non-responsive, ...)

Cheers,
Stefan

from librecores-web.

You are proposing hierarchical categories. I agree that this is probably the best fit for the problem. The database representation requirements of these categories depend on how we are going to use them.

If all we want to use them for is decorating the project page it does not matter that much. However if you want to query the server to get a list of all VHDL projects things get a lot more interesting. For example we could consider not just displaying the categories in the project page, but also adding links to for instance core:riscv allowing the user to get a list of all projects with that category. Are we planning to use the Tags to filter projects?

Who on this project is in charge of the ORM?

from librecores-web.

Yes, this what we are intending. Clicking on the tag brings you to the search page, searching for projects with this tag.

I think the ORM is a common effort. I put up a proposal in the tags branch, input is very welcome.

from librecores-web.

If you want to filter on the server you need to represent the category hierarchy in the ORM. Depending on how many different filter categories you would like to chain you have to have to create multiple fields. If the filtering should be done in js we need a REST API which basically dumps out all projects in json format. I'm afraid there is no middle ground here.

The search page is a misnomer. The page currently located at /search would be normally referred to as index page and implemented as different index pages depending on the model it represents. index pages list the result of a database query for a particular model.

from librecores-web.

Yes, that is the search and it needs serious improvement. The REST API is necessary anyhow, so we probably need to pick it up soon.

The Tagging itself is independent for now I think. I think one level of hierarchy is sufficient and that is currently reflected in the ORM.

Tags are available to typeahead and similar at /project/tags?s=<query>

from librecores-web.

Let me summarize to make sure I understand your plan.

Right now:

• Add a list of tags, each independent of the others (no hierarchy) to the project
• Add a limited project "tag" query to project search page.
• Display the tags on the project page with links to the "tag" search.
• "tags" form: create a new route for the project, something like /{parentName}/{projectName}/edit_tags with methods GET and PUT (I have no idea how the template would look for partial updates.)
• Update the project by adding or removing one tag at a time.

Later, hopefully not much later:

• Add REST API endpoint for project index
• Replace project search by javascript based solution.

Please correct me if I misunderstood anything. Does everybody agree?

from librecores-web.

Roughly yes, just minor additions:

Add a list of tags, each independent of the others (no hierarchy) to the project

They are independent to each other but are from different categories. Those categories are identified by a common prefix (e.g. core:) and a color. For example a core may have multiple interfaces.

Add a limited project "tag" query to project search page.

We should discuss soon an ETA for the new search. If we think this is too far in future, yes.

I have no idea how the template would look for partial updates

Update the project by adding or removing one tag at a time

I saw something here: https://maxfavilli.com/jquery-tag-manager. Not sure how we can benefit from it for adding and removing one at a time.

Thanks a lot for your help!

from librecores-web.

I've been thinking about this topic for a bit now and it's time to get it implemented. I'll take care of the implementation next.

Rough design description

• Bernd is right, "tags" are not the right name -- categories are.
• My plan is to have a faceted classification for projects
• Every project can be assigned to [0;n] categories
• Categories are a hierarchy, which refines a topic

Benefits:

• we have "moderated"/structured classifications
• the hierarchical structure allows users to select wider and more narrow categories based on the individual need

Example

Exemplary classification hierarchy

• language
  • web
    • php
  • hdl
    • verilog
    • vhdl
• proven-on
  • asic
  • fpga
    • xilinx
      • 7series
    • altera
• category
  • cpu
    • out-of-order

So consistent with Stefans plans before, using this exemplary set of categories, a project could be associated with "proven:asic proven:fpga:xilinx:7series category:cpu:out-of-order". Users can use this classification to search both for rough categories (e.g. all projects working on an FPGA by searching/filtering for "proven:fpga"), but also for very specific IP cores (e.g. "all out of order CPUs explicitly running on a 7 series xilinx device with "proven:fpga:xilinx:7series category:cpu").

Related work

• categories in wordpress blog posts
• FSF software directory (https://directory.fsf.org/wiki/Log4c#tab=Details)

I'll next investigate the implementation and get back with a PR soon.

from librecores-web.

That's done now.

from librecores-web.