issues
search
samvera-labs
/
hydra_plugins_wg
Work area for the Hydra Plugins Working Group
Apache License 2.0
1
stars
0
forks
source link
issues
Newest
Newest
Most commented
Recently updated
Oldest
Least commented
Least recently updated
Add justification for "Plugins should use Rails generators for making changes to their host Hydra application."
#38
afred
closed
6 years ago
0
Add justification for "Instance methods that are not part of the plugin's interface should not be public."
#37
afred
opened
7 years ago
0
Add justification for "Plugins should follow established Hydra coding conventions..."
#36
afred
opened
7 years ago
0
Add justification for "Plugins should use semantic versioning."
#35
afred
opened
7 years ago
0
Add justification for "Plugins must have a unique namespace ... "
#34
afred
opened
7 years ago
0
Add justification for "Plugins should be Railties or Rails engines."
#33
afred
closed
6 years ago
1
Add justification for "Plugins must be Ruby gems."
#32
afred
closed
6 years ago
1
Plugins should not monkey patch classes from other gems
#31
afred
closed
6 years ago
8
How to monkey patch
#30
afred
closed
7 years ago
5
Plugins should only generate code into the host app when necessary
#29
afred
closed
7 years ago
4
Generated code counts as the public interface
#28
afred
closed
7 years ago
2
Plugins should not overwrite classes or modules.
#27
afred
closed
7 years ago
2
Plugins must be defined under a specific namespace
#26
afred
closed
7 years ago
6
Adds *must* use routing proxy to guidelines
#25
afred
closed
7 years ago
10
Add guidlines for using YARD and @api tags
#24
afred
closed
7 years ago
1
Named route helpers should be explicit in which route set is being used
#23
afred
closed
7 years ago
9
Will plugins be more specific than a Rails Engine or Railtie?
#22
grosscol
closed
7 years ago
2
Plugins should use YARD with @api tags.
#21
afred
closed
7 years ago
2
Remove contingency language from 'should' statements
#20
afred
closed
7 years ago
1
Installing a plugin should not overwrite classes or modules in the host application.
#19
afred
closed
7 years ago
13
Adds link to Duraspace wiki page.
#18
afred
closed
7 years ago
1
Create initial Guidelines
#17
afred
closed
7 years ago
0
Initial Guidelines
#16
afred
closed
7 years ago
9
Updating dates to 2017
#15
jeremyf
closed
7 years ago
0
Create repo for Google Analytics Hydra plugin
#14
afred
closed
7 years ago
11
Create branch in GeoConcerns for turning into a Hydra Plugin
#13
afred
closed
7 years ago
2
Should "Social Media Features" be be one of our proofs-of-concept projects?
#12
afred
closed
7 years ago
1
Should Questioning Authority be a proof-of-concept project?
#11
afred
closed
7 years ago
1
Initial users stories
#10
afred
closed
7 years ago
1
Should BrowseEverything be one of our proof-of-concept projects?
#9
carolyncole
closed
7 years ago
1
Should Google Analytics be be one of our proofs-of-concept projects?
#8
carolyncole
closed
7 years ago
1
Should GeoConcerns be one of our proofs-of-concept projects?
#7
eliotjordan
closed
7 years ago
6
Installing and configuring a plugin is predictable and straightforward.
#6
carolyncole
closed
7 years ago
2
The interfaces and conventions for plugins are well documented for the developer.
#5
carolyncole
closed
7 years ago
0
The community expectations of plugins are well documented for the developer.
#4
carolyncole
closed
7 years ago
0
The software expectations of plugins are well-documented for the developer.
#3
carolyncole
closed
7 years ago
3
User Stories Vocabulary
#2
carolyncole
closed
7 years ago
4
Adds a roadmap
#1
afred
closed
7 years ago
0
Previous