6 Matching Annotations
  1. Jun 2020
  2. Jun 2018
    1. Citation frequency may reflect a journal’s value, authority, and use.

      Sepertinya ini berkebalikan dengan bagian lain dari artikel ini yang menyebutkan bahwa jumlah sitasi sangat rawan dan mudah untuk "dimainkan". Sitasi adalah hanya masalah seseorang, menuliskan artikelnya (baik milik orang lain atau miliknya sendiri) ke dalam Daftar Pustaka. Bagaimana mekanisme penghitungan metrik seperti ini dapat digunakan untuk menilai kualitas karya atau kepakaran seseorang secara langsung?

    2. Citation performance of Indonesian scholarly journals indexed in Scopus from Scopus and Google Scholar

      Salam dan terima kasih untuk Tim Penulis.

      Secara umum artikel ini patut dihargai, karena penulis telah meluangkan waktu dan tenaga untuk menuangkan hasil penjaringan informasi sitasi dari Google Scholar (GS) dan Scopus yang telah diagregasi SINTA.

      Artikel ini bersifat deskriptif, yang mana artikel jenis ini sering terlupakan, padahal fakta-fakta menarik akan muncul setelah data dan grafik terpampang rapih dalam bentuk artikel. Semoga artikel ini dapat menggugah banyak pendapat yang bersifat argumentatif yang kemudian dapat melahirkan artikel-artikel baru.

      Perkenankan saya meninggalkan beberapa catatan untuk artikel ibu dan bapak ini.

  3. Jul 2017
    1. Thequantitativemethodsintroducedherefindthathigh-throughputtoxicologymethodsarespreadthroughoutalargeandwell-connectedresearchcommunity,whichsuggestshighsocialvalidation

      Metric for "social validation" that perhaps can be used to measure whether a standard has been "adopted by the community>

  4. Jan 2014
    1. This suggests that peer production will thrive where projects have three characteristi cs

      If thriving is a metric (is it measurable? too subjective?) of success then the 3 characteristics it must have are:

      • modularity: divisible into components
      • granularity: fine-grained modularity
      • integrability: low-cost integration of contributions

      I don't dispute that these characteristics are needed, but they are too general to be helpful, so I propose that we look at these three characteristics through the lens of the type of contributor we are seeking to motivate.

      How do these characteristics inform what we should focus on to remove barriers to collaboration for each of these contributor-types?

      Below I've made up a rough list of lenses. Maybe you have links or references that have already made these classifications better than I have... if so, share them!

      Roughly here are the classifications of the types of relationships to open source projects that I commonly see:

      • core developers: either hired by a company, foundation, or some entity to work on the project. These people care most about integrability.

      • ecosystem contributors: someone either self-motivated or who receives a reward via some mechanism outside the institution that funds the core developers (e.g. reputation, portfolio for future job prospects, tools and platforms that support a consulting business, etc). These people care most about modularity.

      • feature-driven contributors: The project is useful out-of-the-box for these people and rather than build their own tool from scratch they see that it is possible for the tool to work they way they want by merely contributing code or at least a feature-request based on their idea. These people care most about granularity.

      The above lenses fit the characteristics outlined in the article, but below are other contributor-types that don't directly care about these characteristics.

      • the funder: a company, foundation, crowd, or some other funding body that directly funds the core developers to work on the project for hire.

      • consumer contributors: This class of people might not even be aware that they are contributors, but simply using the project returns direct benefits through logs and other instrumented uses of the tool to generate data that can be used to improve the project.

      • knowledge-driven contributors: These contributors are most likely closest to the ecosystem contributors, maybe even a sub-species of those, that contribute to documentation and learning the system; they may be less-skilled at coding, but still serve a valuable part of the community even if they are not committing to the core code base.

      • failure-driven contributors: A primary source of bug reports and may also be any one of the other lenses.

      What other lenses might be useful to look through? What characteristics are we missing? How can we reduce barriers to contribution for each of these contributor types?

      I feel that there are plenty of motivations... but what barriers exist and what motivations are sufficient for enough people to be willing to surmount those barriers? I think it may be easier to focus on the barriers to make contributing less painful for the already-convinced, than to think about the motivators for those needing to be convinced-- I think the consumer contributors are some of the very best suited to convince the unconvinced; our job should be to remove the barriers for people at each stage of community we are trying to build.

      A note to the awesome folks at Hypothes.is who are reading our consumer contributions... given the current state of the hypothes.is project, what class of contributors are you most in need of?